Skip to main content

Static Vs Dynamic libraries in iOS

A library is a collection of resources and the code itself, compiled for one or more architectures. Apple provides 2 types of library architectures that behaves differently upon building our app.

Static libraries (*.a) : 

When the app launches Static libraries loaded into address space for future use. They become part of the executable, and are statically linked to client apps. Thus, it (especially large executable libraries) makes apps slower to load and run, even launch time of the apps.

Apple shown the architecture of static libraries as below :




Dynamic libraries (*.dylib) : 

With dynamic libraries, the app loads code into its address space when it’s actually needed, either at launch time or at runtime. The libraries are not part of the executable file. Thus decreases the memory footprint for your app.
Clearly dynamic frameworks has got more advantages over static frameworks. Notably, it is available for iOS 8 and above.

Apple shown the architecture of dynamic libraries as below :


Developer involvement: 

 Xcode produces 2 files when Dynamic libraries are build - 
  1. Simulator Architecture file
  2. Device file
We need to switch files whenever app requires to change  production and test mode.

Note: The target architecture of the client and the dynamic library must be the same. Otherwise, the dynamic loader doesn’t load the library.

So what do developer need to do to use our dynamic frameworks?
 We can add them to our project via the Embedded Binaries section (project general tab) and before deploying app to the Apple store, just add a custom script (copy and paste from the documentation) to your app’s Build Phases, build it, and the simulator architecture will be removed from the framework as Apple requires.

For make developer life easier, it is highly recommend CocoaPods. All of the build settings and script is automatically handled by CocoaPods, so you don’t need to do anything at all.


Popular posts from this blog

Animating label text update - choosing a better way

Recently I published a countdown app .  At one point of development - I have to show a timer on a UILabel which ticks on each seconds. As usual I started  setting text to a label object - self .timerLabel.text = someString Easy piece of cake right !?   But wait ... it won't take much user attention when timer ticks on every seconds. So I decided to make use of a simple animation while label gets text update. I found there are dozens of ways to animate a label. In this short article, I listed 3 best way you can animate text on a label. ( Spoiler Alert 👀- I decided to go with 3rd option)  1. Fade In - Fade out animation : CATransition class has got transition type `fade`. With timing function of CATransition - I was able to see the below result. let animation: CATransition = CATransition () animation.timingFunction = CAMediaTimingFunction (name: CAMediaTimingFunctionName .easeInEaseOut) animation.type = CATransitionType .fade animation.subtype = CATransitionSubtype .

Prevent Navigationbar or Tabbar overlapping Subview - solved for Card view

Recently, I started with a Card view added as a subview of UIView in a view-controller. When a view controller created along subviews, it tends to use entire screen bounds and also slips behind Tab bar or Navigation bar. In my current situation, it's second case. Casually new iOS developers will write a patch by additional value for coordinate y and subtracting bar height from its size. A lot of them posted in SO threads too : How to prevent UINavigationBar from covering top of view? View got hidden below UINavigationBar iOS 7 Navigation Bar covers some part of view at Top So, how I got solved ? self.edgesForExtendedLayout = [] This  will avoid all subviews in a view controller get behind any bars. Read full apple  documentation on here. Full Source code below :  //Simple view controller where its view layed-out as a card. class WidgetCardViewController : UIViewController { var containerView = UIView () //MARK:- View Controller Life Cycle ov

UICollectionViewCell shows with wrong size on First time - Solved

We commonly use Collection view where its cell size calculated run time. The flow layout delegate is responsible to return individual cell sizes. BUT in most of the cases, delegate method `collectionView: layout sizeForItem:` expects cell size too early. Before generating actual cell size. extension YourViewController : UICollectionViewDelegateFlowLayout { func collectionView ( _ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAt indexPath: IndexPath) -> CGSize { return CGSize (width: externalWidth, height: externalHeight) } } For instance, if a cell size depends on external view and its frame is not yet ready - results with wrong (or outdated) cell size. Typically happens for the first time view controller laid out all views. You can find similar queries in StackOverflow community : Collection view sizeForItemNotWorking UICollectionViewCell content wrong size on first load How to refresh UICollection

Implementing autocompletion OTP field in iOS

Long waiting is over. !!  iOS 12 brings Autofill for OTP text field which is close to Android provided a decade back. Previously in iOS we used to toggle between OTP text screen and message inbox.  Which was hard to remember and time consuming resulting a bad user experience. Personally, I have been asked from the client/customer couple of times to implement autocompletion for OTP field and took me a lot of time to convey that it is not possible in iOS. Why Autofill was not possible previously?  We all know that Apple gives at most care for user privacy. When we see iOS architecture, each individual app is like a separate island. There is no inter-app bridge between apps (exception for Keychain and URLSchemes APIs which gives very limited scope). Thus we cannot read message content from inbox. Where to start Autofilling? First of all, the target SMS need to have the OTP Code with prefix string "Code" or "Passcode"on its message content. Beware of OTP c

Static variable vs Class variable in Swift

How Static properties differs to usual properties ? Used to create type properties with either let or var. These are shared between all objects of a class.  During class loading time, a single memory location allocated for the property if we declared as static. Static property belongs to a class (or struct) Type rather than Instance of class (or struct). Hence it also called  Type Properties What if we declare "static var" ? Since it's a variable, we can change it in future even after initialised. When we change the value of the static variable property, that property is now changed in all future instances. What if we declare "static let" ? static let instance : Singleton = Singleton() Since it's constant, we cannot change once initialised. Its value will remain same even if we share among all the instance or object of a class or struct. Useful to adopt singleton pattern. How class variables differ static variables ? It dif