What is the proper way to link a dynamic framework which lives in the same workspace like the app?
I have a problem when adding the framework from the products folder to the App's "Embedded Binaries" section - because the added framework may be built for simulator and the app builds against iphoneos. I can not add both, can I?
I want to achieve that when my app builds, the framework is built too and I can work the changes immediately instead of doing some cumbersome update via Carthage or something link that.
EDIT: http://netsplit.com/xcode-two-apps-with-a-shared-private-framework-in-a-workspace This blog post describes exactly what i want to do - but this does not work since i want to develop on simulator and iphone (it would require a fat framework). Or did I miss something.
Although is possible to develop main app and framework and doing integration test in the same time from many workspaces, at same point becomes a slow-ish and not scalable development process.
So I suggest you to make a sample app in the workspace of your framework and develop and test your features directly from there. Once your framework is quite stable you release it and you integrate it with your main app.
Related
I have an Xcode swift app that uses "import CoreBluetooth" to access a wearable.
Now, my teammate wants to use my functionality, and thus wants a lib (.a) that he can incorporate into his xcode GUI app.
Can I refactor my app into a lib for him to add to his GUI app?
Or, is the only way to create a new xcode lib project?
Short answer is yes, you can use the same project. You need to separate 2 things:
Project is a design-time / code organization entity. One project can contain framework, app, tests, etc - all at the same time
What actually dictates what is going to be built are Targets. Some targets will build an app, some will build the library etc. Each target may contain any subset of files from your project (as long as they compile).
So that's one way to go about it: create a second target for Framework, add relevant files to Build Phases > Compile Sources and voila.
The advantage is simplicity. The disadvantages are many: how do you know you didn't break compatibility with wearable? how do you know which file belongs to app, and which belongs to app and framework (sure, you can see when you click on file, or folder structure can help, but it's not going to stop the mistake from happening)? or what if compatibility your iOS app needs is different with what wearable app needs? how do you maintain versions of such framework? etc etc
So a much better cleaner way is to create a separate repo for your framework, and maintain it as an internal product you are sharing between various components. That way you can maintain clear versioning, compatibility, and address bugs without the fear of breaking either app or wearable. And you can include that framework in both projects using (like suggested above) Swift Package Manager, or CocoaPods, or even manually.
We have built an awesome Flutter project, which has great functionality we want to export as a framework, just like native libraries do, so that the source code is hidden (convert to dynamic framework).
We have followed the instructions: https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps
which allows us to include Flutter project in a Host iOS app, initializing FlutterEngine and use of FlutterViewController.
The question is, how do we create a dynamic framework, let's say SomeProductSDK.framework, which will expose a public methods to create our SomeProductSDK related modal screens?
// In any app
import SomeProductSDK
let controller = TransactionViewController() // SomeProductSDK.framework with partial implementation with flutter
self.present(controller, animated: true)
I've partially achieved what you want. All of this is very experimental and overall a bad idea for production ready SDK. But... it's possible.
Create flutter app as usual and run it once on iOS simulator.
Open Xcode workspace and add new framework. For my purposes I will name it RunnerLib.
Change deployment target of that framework to be the same as for Runner. Also disable bitcode.
Change target membership of App.framework and Flutter.framework to RunnerLib.
Create Launcher class with one static method: + (void)launchFrom:(UIViewController *)parent, this what should create a FlutterViewController and present it.
Rewrite the Runner to use Launcher class. Replace FlutterAppDelegate with standard AppDelegate, make ViewController, etc. It should look like standard native iOS project, so you could create one and copy over AppDelegate, storyboard and ViewController.
Call launchFrom method in your view controller, in viewDidAppear or as IBAction on a button.
You should be able to build the Runner and see that flutter screen appears.
Now, if you build the Runner app, you can open the crated Runner.app, and see that Frameworks directory contains 3 frameworks: App, Flutter and Runner.
You will need to have two sets of frameworks: one set for simulator, compiled in debug mode, and another set for devices - archived. Getting debug frameworks is pretty easy, just compile from Xcode and inspect the product. Archived frameworks are harder, I recommend doing xcodebuild archive with disabled signing.
Your users will have to configure their project to use correct frameworks depending on device. Possibly this step can be automated by Carthage and fat binaries, but I'm not sure. The problem is with App.framework which looks completely different on device than on simulator.
Source code: https://github.com/szotp/runner_lib
In order to export the framework as a native library you'll have to ensure that the person who'll use your framework (user) has Flutter SDK installed onto his computer as your framework's code will surely be dependent on Flutter SDK by default. So what your trying to do is equivalent of having your own package on pub.dev.
If you find some way to make the framework you want to export - independent of Flutter's framework, only then exporting it as an framework would make sense. (Doing that should be possible beyond doubt, but see the amount of work and time you'll put in just to get your framework there. You could have built your own Flutter framework in those same efforts and time)
Since you have already made that awesome Flutter Project, consider uploading it as an package on https://pub.dev/ if you wish to.
Suggestion: You can ask the users who want to try your package to install Flutter. This way your hardwork won't go in vains.
Conclusion: It is not practically feasible to achieve what your trying to do.
Thanks for spending time reading my question.
I've been working as an iOS developer for more than 2 years and today I still feel shame because I don't know how to deal with frameworks. I've build some projects using my own frameworks, but I've never understood exactly what's the best practice doing this.
Lets see the following example:
Project -> FrameworkA -> AFNetworking - Charts - FMDB - more
So, I have a big FrameworkA with mostly all the app behavior and then a small project referencing this FrameworkA and customizing just icons, texts and images. I use to manage dependencies with CocoaPods and I would like to use it with FrameworkA. By this I could reference external libraries easily, but it seems it doesn't work for frameworks, only for projects. So, my questions is: how can I add AFNetworking, Charts, FMDB, etc to my FrameworkA and then reference the framework form my project?
I appreciate if you can give me some idea using CocoaPods or any other dependency manager. I don't like the old way by doing this manually.
I hope my case is clear.
Thanks!
It sounds like you are asking how to embed external frameworks such as AFNetworking into a framework you are developing, and then use that framework in your app.
This is what's known as embedded frameworks where one framework is stored within another. Generally speaking it's not a great idea and should be avoided because it can cause version clash issues.
The way I'd recommend doing this is to use CocoaPods or Carthage to link the external frameworks (AFNetworking, etc) into your framework project. But do to try to embedded them.
Then in your app project, again use CocoaPods or Carthage to link in your framework (you won't need to link the external ones unless you are directly using them in the app code). Then add the necessary build steps to copy both your framework file and all the external framework files to the finished app's framework directory.
For implementing our unity3d project into iOS, we need to manually select/tune a long list of tweaks in xcode build menu every time we build the project to test it (mainly to use appodeal framework).
Is there an easy way this task can be automated?
for example, in android builds, I reuse the same manifest file for the project and everything works just fine. Is there a similar way for xcode?
This is Andrew from Appodeal support. In the last release of Unity plugin (0.4.9) we have post build function which can help to resolve this issue.
You can download it here: Download_link
I have created a dynamic framework for one of my apps as I was using a lot of the same code for the main app and the extensions. This works well and has reduced the amount of duplicate code in the project.
I am now looking at creating a second app and it would save me a huge amount of time if I could use the framework from the first app.
How would I go about doing this?
My initial thought is to break the framework out into it's own project and include that project in the app projects by using a workspace.
Another thought was to have both apps in the same project, but as different targets.
I also use git, so it would be beneficial to have the framework separate from the apps.