Do iOS Apps Share Frameworks

Do iOS apps share frameworks?

If it's a system-provided framework, then every app uses the shared system copy of the framework. If it's a framework you downloaded and added to your project, then your app uses that private copy. (The same is true for OS X apps and frameworks).

(Note that non-system iOS frameworks must be static, so they wouldn't be shareable between apps anyway. But, this answer would hold true even if dynamic library frameworks were possible, as is the case on OS X).

Does iOS lost most of the advantage of using dynamic frameworks?

You're correct in all of this. Non-system (i.e. not provided by Apple) dynamic libraries going to be less efficient in pretty much every way on iOS. They give you no space or memory savings, and they cost you at launch time.

The old Apple document you reference was almost entirely written before the iPhone. It's referring to late-loading libraries in Mac apps, which can help launch time.

On systems with shared libraries (or when using system libraries, which are shared on iOS), dynamic libraries save disk space, and can be shared between processes which saves memory and load time (because it's already loaded by some other process). But if you don't share the library, you can't really get any of those benefits. On systems that allow runtime loading of libraries (not iOS), dynamic libraries can delay the cost of loading seldom-used code, possibly indefinitely (if the code is never used). Furthermore, it opens up the opportunities for plugins and other extensions.

Is it possible to share an installation of an iOS framework you have created between multiple apps?

Nope.
Your own frameworks are restricted in its own sandbox

How do I find out if an IOS app uses frameworks/framework libraries

Finding out what frameworks an app in the Appstore uses may be a futile process, but it is possible to find them if one has an ipa file. Here is the process:

  1. Convert the ipa file to a zip file by renaming it to ".zip" instead of ".ipa". For example, "test.ipa" should be renamed to "test.zip"
  2. Unzip test.zip using whatever tool you chose.
  3. Navigate to the test/Payload. You should see a ".app" file in that location.
  4. Right-click on the file and select "Show Package Content" in the popup menu.
  5. Expand the frameworks folder to view the frameworks. Files within this folder have the ".dylib" extension.

Integrate two massive apps as frameworks into one Xcode project

Too big for a comment, will post here. I did something like that in the past, and the steps were something like this:

Step 1: Turn each heavy app into light app + (heavy) framework within the same workspace.

Make your light app depend on heavy framework and get that to work. I would start from creating an empty framework, getting it as dependency to the app, and then gradually migrating classes - group by group, merging each group (even if it's not final).

You won't be able to migrate everything from the app, but it will tell you how you will have to integrate with that framework. For example things like entitlements, AppDelegate etc will remain in the App. But most of the code will be in the framework, buildable as a separate framework target.

Step 2: Once each app is converted, you can create a completely new app, drag & drop your frameworks into that app (to begin with, you can do something better later), and use code from both "light" apps to integrate with your frameworks.

You will need to bring all the pods, and may need to resolve some conflicts at this point too.

Step 3: Once your new app is working, you can figure out how you will actually deliver frameworks to that app: is it going to be private pod, or drag & drop, or anything else.

Can I package entire iOS app as a Framework?

There are obviously a lot of options around this as far as design/approach.

I've done this multiple times (with apps live on the app store) and really it's just like developing any Framework.

First: AppDelegate. The easy way around this is to have the app's AppDelegate subclass your Framework's AppDelegate:

@UIApplicationMain class ParentAppDelegate: FrameworkAppDelegate { }

Just make sure the App calls super on all the relevant methods.

Second: Dependencies. This is probably the most annoying part since Frameworks can't embed other frameworks. But you still have a few easy options:

  1. Have the enclosing app embed the needed framework
  2. Add the sources of the needed framework directly to your framework.
  3. Use a dependency manager (e.g. cocoapods) that takes care of this for you.

Other Concerns: One trap you can easily run into is working with Bundles. Anytime you dynamically load images/strings/IB references/etc. you will need to specify you're using the Framework's bundle, as at times it can default to using the app's bundle. The easiest way to do this is with this init e.g. Bundle(for: self.self)

Also keep in mind that the settings in info.plist and entitlements your framework needs will need to be added by the parent app.

General Comments on Approach: My advice (take it or leave it ☺️) would be caution around simply adding your full application to a client's application. Aside from IP and App-Review concerns, it can result in adding a lot of complexity or a fork of your current application to support it, making future maintenance a hassle.

Instead I would recommend putting only the portions of the application your client requires into a separate framework that both you and your client use for your separate applications.

Combined Watch OS and iOS Framework

I wound up finding the answer buried in the documentation right after asking it... Rather than delete the question I will post the answer here for the interest of others:

According to Apple you cannot share frameworks between the watch and phone. Specifically:

Sharing Code Between an iOS App and a watchOS App

You can share code, but not frameworks, between your iOS app and Watch
app. Because the apps run on separate platforms with different
architectures, source files must be compiled separately for each
platform. If you still want to use a framework to manage any shared
source files, you must create separate framework targets for each
platform and add your shared source files to each framework.

If you already have an iOS framework, you can duplicate the framework
and modify it to support watchOS.

https://developer.apple.com/library/content/documentation/General/Conceptual/WatchKitProgrammingGuide/iOSSupport.html#//apple_ref/doc/uid/TP40014969-CH21-SW1

Avoid other apps using the same framework to access the keychain data in iOS

That's the default situation. Each app has its own access group by default, and things put into Keychain are limited to that access group. The framework isn't relevant, only the app ID (and by extension the access group or groups).

For more on access groups, see Sharing Access to Keychain Items Among a Collection of Apps for how apps (from the same development team) can share Keychain items. But the default is that they don't.

What is the difference between an app project and a framework project in Xcode?

An App is a standalone application that can be launched and run. For example, all of the apps that you have on your phone are just that -- apps. You tap on them and they launch and run, presenting a user interface, accepting input, etc.

A framework is something else entirely. It's a collection of code that is bundled together into a package that is used by another framework or by an app. Some frameworks are provided by the system -- for example, SwiftUI is a framework that it sounds like you're using in your app. Other frameworks are provided by 3rd parties. For example, you can find many frameworks via CocoaPods or the Swift Package Manager -- Alamofire is a common example. Also, you can make your own frameworks and use them in your own code as a form of organization and separation of responsibilities.

Why is it more advantageous to have my project as a framework?

It is not -- they are two almost completely different concepts (besides both ultimately being collections of code and resources). If you intend to build an app that is launch-able on someone's device, your only choice is to make an app. If you intend to make a collection of reusable code for use in your or someone else's app, than you would make a framework.



Related Topics



Leave a reply



Submit