So I watched the whole video ("Building modern frameworks") here and I still have some questions. The last 11 minutes is the actual demo if you want to watch it, but to sum up he creates a framework and then stops. He does not show how to share it or place it in other projects.
1.) In order to use the frameworks in other projects I have to import both the simulator framework and the device framework to work? Is that correct?
2.) Can I copy the actual framework out of the build folder to use in other projects?
3.) Is it possible to keep the framework up to date among different projects? Like change method A in the first project and the change is also visible in the second project?
4.) The guy from here has also an option for keeping pieces of code in sync with different projects. In short: He makes a project (framework) places all the code in it who should be the same in other projects. He then copies the framework in other projects and does not copy the framework in there, but just links it. Is this a good method? Will this be accepted by Apple?
Related
I am working on a project with SwiftUI and it originally started with creating a new project as an "App" (Xcode, clicked on file, new, project, click on "App") but was then later asked to put it into a pod as a framework. I did it successfully (Xcode, clicked on file, new project, click on "Framework"), however I am unsure what the differences are and I'm unsure why I would want to do that. To me they look very similar, except that I'm unable to launch my project as a framework in the simulator. Luckily SwiftUI offers the canvas preview window however it is a bit finicky when it comes to certain button interactions, which is why I am wanting to use the simulator.
Two places of confusion:
What is the difference between an app and a framework project?
Why is it more advantageous to have my project as a framework?
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.
Excellent answer (and upvoted) by #jnpdx. Let me give you a physical example:
(1) Create a project in Xcode that is a framework. Call it "MyAppKit". Inside it create, well, basically anything - a View, UIView, or more likely a function that will be shared by several views. (Let's go with that.)
public func setLoginName(_ login:String) -> String {
return ""Hello, " + login + "!";
}
Pretty simple. Call it, pass in something, and it returns a string saying hello. Please note the public piece. It matters. (And there's much more there. This is a simple example.)
(2) Now we get to your app or apps. Let's say you have two apps that need to use this (again, very simple) code. One is SwiftUI, one is UIKit. (It doesn't matter except for syntax.) Sine my forte is UIKit I'll use that. (And it can be several dozen apps too.)
import MyAppKit
let myLoginMessage = setLoginName("World").
Pretty much, it's "Hello, World!'
Again, this is really a nonsensical example. But it should get you started on what the difference in Xcode is between a Framework project and an App project is.
I have an objective c project in Xcode wherein i must have two apps with complimentary functionality. For convenience I have written all of my functionality inside one app but now I need to really separate this into two distinct apps. My question is about how to go about creating the second app. Should I just duplicate the Xcode project folder and make my changes there? I've also read a little about targets. Is that a potential solution to this?
Yes, it sounds like adding another target to your existing project is the way to go for what you're trying to achieve. This article might prove useful to you: https://itexico.com/blog/iOS-Mobile-Development-Using-Xcode-Targets-to-Reuse-the-Code
Yes, target is the way to do it.
Useful link to understand what it is:
https://developer.apple.com/library/ios/featuredarticles/XcodeConcepts/Concept-Targets.html
It depends how the two apps will differ. If the GUI will be very similar then different targets would do.
But if you want flexibility to change the GUI of each app by big amounts then you could create separate projects but put common model functionality into a library which is linked to by the different projects.
Yes you can achieve it by following approachs
Adding a new Target and reusing the code and resources
Or create a framework in a generic way and pull all the reusable codes and resources in that, through this you only need to drag and drop the .framework file in any of you current or future models.
I suggest go with framework
I built an iOS project (actually workspace because of Pods) that is 100% functional, with its logic and UI (Storyboard and xibs). Now I would like to reuse this app/project as a "core" for future apps.
I've been searching about it and there are several solutions like Static libraries, Frameworks and Targets. But I am not sure which one would be the best in my case. I would like to reuse all the UI part as well.
I saw that most of the people agree that the best approach for reusing code is static libraries, even thought it looks not so straight forward. But I think for reusing UI probably Targets is the best solution. The problem I see is that if a build 10 apps based on my core project, the new project will be huge, so probably it is not the best option.
I don't know if you guys have any better idea or opinion.
Thanks in advance!!
There are several things you can do, and I will try to go through them.
If you have minor changes on your "base" app, then the best thing would be using targets(build schemes). This way you can add things to build phases and therefore, add files that you need. This might be the quickest possible way to do what you want but here are some drawbacks: What if you have 5 apps, and for each one you have QA and prod. That 10 build phases. If you keep using your app in no time you will find hard to manage it.
Another thing could be to create different project, and include all the files you have (and you need), inherit from there and have extended functionality/UI/UX. This is slower approach then number 1, but you will have dependency on the files that you might change in one app and don't want to propagate that change in other apps. So the drawback would be that you have to be extra careful, and plan a lot of things in advance.
Third thing could be to create base app group(or project) and then you are certain what to do, where and what that change could do to other apps(since you know that this file is actually being reused).
And finally, there is a framework, which is my favorite. I am working on one project that inherits base app and we found that is a huge problem. You start separated and then, one thing by one, you have entangled code for specific app and base app like headphones in pocket. And if you don't refactor it ASAP, it will became really hard to resolve these kind of issue. Not to mention merging and other stuff. Here is an excellent article about creating framework http://www.raywenderlich.com/65964/create-a-framework-for-ios . Off course, there is a price to pay and that's every change that you create you must update library and add it again to project. This thing can be easily forgotten and if you are working in team could produce build crash.
All after all, you predicate that you will have more then 5 apps, so I would say go with the framework. This way you will have much cleaner and separated app, and won't have to think about changing things and how these changes would affect your other apps.
I recommend you use a custom project template. I did it perfectly today. I had the same needs as your. Follow this link: https://github.com/reidmain/Xcode-6-Project-Templates/tree/master/iOS%20Application.xctemplate
Download it. You can add all the files from existing project into this template, storyboards too. If you have any doubts I will help you.
I'm doing a series of book apps for a client. There's a lot of books in the series, and each one will be a separate app. Instead of making changes to all the apps every time they want something tweaked in all of them, like the position of a button or something, I'd like to make a universal "framework" (library?) that I can import to a project, just as I would do for one of the iOS SDK's frameworks. The framework would have all the universal components of the apps, which would include a controller class I would subclass in each app to do the app-specific things. Then when I need to make changes to all of them, I could just change the code in the framework, and it would affect all the apps that use it. I'd also like to be able to include common images and other media.
Do I want to use the "Cocoa Touch Static Library" template in Xcode? I also saw this project in github: https://github.com/kstenerud/iOS-Universal-Framework; would this be a better fit for what I'm trying to do?
For your purposes, the simplest approach would simply be to set it up as a static library project. Then, for each application you want to use it, drag the project into your workspace and add the static library product as a dependent target.
As far as I am aware, the current leading method for building a framework on iOS is Jeff Verkoeyen's iOS-Framework.
I have my first iOS application under my belt (a relatively straightforward iPad app, to be released in a month or so), but now I'm moving on to something more ambitious, and could use some advice.
My next project will actually be two distinct but closely related iPad applications that will share quite a bit of core functionality and a common data format. So my instinct is to develop these two applications in conjunction with the development of a core framework shared by both, and I'd like this shared framework to use CoreData and also provide GUI elements (NIBs, view controllers) that can be used by the respective apps. My further instinct therefore is to create 3 Xcode projects: one iOS app project for app A, a second iOS app project for app B, and a third, CocoaTouch framework project for the shared framework.
Questions:
1) Is this the right way to structure my development, or is there a better way to do concurrent development of two closely related apps and a shared framework?
2) Can a framework use CoreData? (I ask this because when creating a CocoaTouch framework project in Xcode one isn't offered the option of having it use CoreData -- nor the option of having units tests -- as one is when creating an iOS app project).
3) Is there a way to "convert" an iOS app project into a framework project, or, perhaps preferably, rather to build an app project into a framework target? That would let me create the framework project with all the Xcode setup freebies (NIBs, core data, etc.), instead of adding all that stuff manually.
Thanks!
Carl
To answer question one, I wouldn't work this way. I would create one project with three targets, two app targets and a framework target. Maybe in the future I would move the framework to its own project when it had stabilized and if I was going to use it for even more iOS apps. Having all the targets in the same project reduce synchronization problems when working on code shared among the targets.
To answer question two, Xcode just doesn't include the template support to add Core Data and unit tests to a starter framework project. I see no reason why you can't use Core Data in a framework.
To answer question three, just add a framework target to your iOS app project, and move the appropriate portions of your iOS app to the framework.