Swift is fast, safe and expressive language to code with great full stack potential and community support. According to Apple, it’s 2.6 times faster than Objective C (As a Swift Developer I agree on this too 🙌). It’s 6th most loved language on StackOverflow.
ABI Background As a developer, I hope sometimes you also felt that Swift is not mature enough as every year major changes are being introduced. One of the key problems articulated by a lot of developers is “Lack of backward compatibility” and you have to choose one Swift version for your Xcode projects (Version lock). Resulting in with a new Swift release you have to make changes in your existing code.
What is ABI? ABI stands for Application Binary Interface. During runtime, Swift program interacts with other libraries through ABI (low-level set of protocols for memory representation, function calls, and access). So when I say ABI not stable it means that each binary is building its own version of Swift Dynamic Library inside it. Now the Swift 5 is ABI Stable which means if I build two apps, one using Swift 5.0 and another using Swift 5.2, both will use Swift ABI embedded in the iOS Operating System.
Why ABI Stability matters a lot?
Compatibility: which means new compilers can compile your old Swift code which means no more migration pain.
Bundle Size: It will reduce the build size because of no Swift standard Library in your Framework folder.
Binary framework and runtime compatibility which enables the framework distribution as a binary which will work across multiple Swift versions.
Conclusion: Swift is the future for Apple ecosystem and now it’s ABI stable which means, in other words, it is like write once and use everywhere.
Is it more important for the software system to work or is it more important to be easy to change? If you ask the business managers they will say work is more important, some developers also go along with this attitude but that’s the wrong attitude.
Why the wrong attitude?
If you give me a program that works perfectly but impossible to change, it means it won’t work when the requirements change.
If you give me a program that does not work but easy to change, it means I can make the change to make it work.
If you’re a programmer with the attitude (1.) then one day your system will reach to the point where the change will be impractical (cost of change will be unaffordably high).
Eisenhower said, I have two kinds of problems, the urgent and the important, where the urgent are not important and the important is never urgent.
when it comes to software, The first value of software is behavior, is urgent but not always important. The second value is architecture, is important but never urgent. Of course, some things are not urgent and not important.
Urgent and important
Not urgent and important
Urgent and not important
Not urgent and not important.
Mistakes that business managers and developer make is to elevate items in position 3 to 1. It means they always fail to separate those features that are urgent but not important from those features that are really urgent and important and this failure leads to ignoring the important architecture of the system in favor of the unimportant features of the system.
So if you are a software developer, you are hired to maintain the quality and structure of the system and only you know the importance of the architecture.
Thanks for reading it, if you want to read in more detail, buy “Clean Architecture by Robert C. Martin”
Properties of a constant instance of the struct are immutable because struct’s instance own the whole object and by declaring it as a constant means the whole object itself will be immutable.
Properties of a constant instance of the class are mutable as class’s instance owns the object’s reference thus by declaring it as a constant only means that the further reference assignment can’t be done.
Structs are blessed with default member-wise initializer but classes are not.
Structs are preferable when they are small and copyable.
With Structs, there is much less need to worry about memory leaks or multiple threads racing to access/modify a single instance of a variable.
Since struct instances are allocated on the stack, and class instances are allocated on the heap, structs can sometimes be drastically faster (but it still depends on how many values you’re storing and the size/structure.)
In a multi-threaded environment, for instance, with a database connection that’s opened in a different thread, structs are safer. They can be copied from one thread to another thread, without running the risk of a race condition or deadlock. Classes do not have this inherent safety unless they’re deliberately made thread-safe.
How to use Swift classes into Objective Code when you have multiple targets.
For using Swift classes in Objective-C Code when you have one target in your app. We generally need to andimport TargetName-Swift.h next to add support in your Swift file you need to inherit if from NSObject or use @objc flag.
What if you have multiple targets in your codebase? As you cannot import, TargetNameA-Swift.hTargetNameB-Swift.h etc. In that case, you can tell the compiler that not to create Swift module specific to target change it to project name because the project will be same and unique.
For achieving this select your every target, Build Settings and change the build configuration.
Objective-C Generated Interface Header Name —> replace$(SWIFT_MODULE_NAME)-Swift.h that is specific to the each target, with $(PROJECT_NAME)-Swift.h
Later import PROJECT_NAME-Swift.h in your Objective C code to make use of your Swift code.
Lots of developers consulted with me regarding on how to use storyboard with too many team members like when you have 20 developers on your team? So I have collected my thoughts on that today. I have used Storyboard as well as XIB so here are my thoughts on both.
Storyboards are the really nice way to see complete application flow without running into Simulator, you can see the screen flow and the navigation between them, it’s one of key thing that makes your application architecture better.
For a larger team of multiple developers it’s really difficult to use the same storyboard because at the end it’s XML file so really very hard to merge and you will end up with a lot of conflicts, So I have noted, a lot of developers suggest XIB here but I don’t see any reason why they choose XIB and I think the best idea is the divide the complete application in different storyboard according to their use-case, that is the first activity I always do, divide complete app into as much as possible storyboard you can (but it’s not like 1 storyboard for 1 ViewController) and use storyboard reference to connect them.
I worked in rapid prototype development (deliver the complete application in 15-20 days, developed POC in 7 days) so the biggest benefit that I earned from storyboard is Mock-up, I can create complete app mock-up without writing a single line of code and really easy to manage the transition between views.
Few issues that I feel with the storyboard is, it fails at runtime means if you made a mistake with segue name, the class doesn’t exist etc. Yes, it gives issue at compile as well only if you didn’t merge it properly (merge conflicts with XML tags).
Using Storyboard, no need to run your app on the different simulator to verify the UI, it gives you fantastic feature called preview (Click on the Assistant editor, select your storyboard, choose automation to preview).
Developers say it’s harder to reuse the code in storyboard but my opinion is, first think and implement, try to use mix approach with the storyboard, XIB (wherever requires use XIB to make it reusable on different storyboards).
Yes, storyboard creates an issue when you create one in Xcode 8 and try to open it in Xcode 7 but lots of developers already raised this concern with Apple so hopefully, we will hear something from Apple soon.
Thank you for reading! Please do share your thoughts if any.
STUPID principles and yes this may hurt your feeling but yes if you are following this you are writing stupid code.
Well known design pattern, but mostly understood one as well. Like me, people are also fighting with Singleton syndrome. In that case, whenever we create a class we create it Singleton but why? That is definability not cool. Singleton also considered anti-patterns. We should think and avoid if possible because the program using Singleton are hard to test because of global state, with the global state they hide their dependencies.
Avoiding static things is important to avoid tight coupling. If it’s there then making a change in one module requires to changes another module too. Now it’s really difficult to reuse and difficult to test.
Testing is not hard, what you think? We don’t write test case may be because we don’t have the time or the code we are writing is bad because of tight coupling?
One of my favorite quote from Donald Knuth, premature is the root of all evil. There are only cost and no benefits. Actually optimised code is much complex as compared to just writing a loop.
That’s what I like most and I try to follow as much as possible. Name of your class, variables or methods should be clear because at the end of the day human is only going to read because programming languages are for human not for computers, computers can understand 0 or 1 very well.
That’s bad. Writing same code again and again so don’t repeat yourself, keep it simple and strong. Write Code only once.
Thank you for reading the quick introduction of STUPID principles, next will be SOLID principles.
SOLID principle is an acronym created by Robert C Martin also unknown as Uncle Bob. It represents five principles for OOPS.
Single responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion
Now the first thought that came to my mind is Why do we need this? Here is the answer, using these principles we can solve the problems of a bad architecture.
Fragility where A small change may break complete module it’s really very difficult to find this if you don’t have good test cases.
Immobility where A component is very hard to reuse in another project or we can say multiple places in the same project because of too many dependencies.
Rigidity where Single change requires lots of developer efforts because it affects several parts of the project.
Here I want to add principles will not turn a bad programmer into a good programmer you need a better judgment there. Principles have to apply with judgment and you must be smart enough to understand when to apply what.
I have also written one blog where they have mentioned one more acronym like SOLID and it’s STUPID. This may hurt your feeling but yes if you are following this you are writing stupid code.