iOS 12, Xcode 10.2.1, Swift 5
I've been working on two apps for the same company, one app is aimed for normal users and the other app is for agencies. Both apps share 80% of code and views (Storyboards or .nib files).
As we were on a hurry at the beginning, I created two Xcode projects and worked on each app separately. Now we're in a refactoring phase, and it's painful that whenever I wanna change something that is common, I have to change it in both projects, which means two code reviews and two new branches and two new merges into master every time.
I read about these three approaches:
Targets: But I really don't know if targets solve my problem, and how to merge the two existing projects
Workspaces: Don't know if this solves my problem, especially that each project uses CocoaPods (almost the same pods)
Building a framework: I tried this approach but using the framework in both apps and on both simulator and device was also a huge pain and I dropped it after I tried to run scripts and figure out a way to make the framework run on both simulators and devices after archiving it.
Does anyone know how to manage such thing without messing both projects?
Related
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?
I have 10 ios apps which have same UI and almost same functionality except minor changes.
I have completed one app and want to make other 9 app and also used some 3rd party libraries and made changes to them and made some my custom functions for app functionality.
My concern is that if i will get change for even one functionality , i have to make that change to other 9 apps.
What is the the best and fastest way except changing code in each file ?
You should keep one codebase and add multiple targets to it.
This way you can write both target specific code, and generic code.
You can read up more on this here One Codebase Multiple Targets
and here Apple Xcode Targets
Hope it helps
I have a number of apps (about 16 at the moment and growing) which have pretty much identical code. That is the code that drives them is the same.
There are a few things that change between apps, they are:
A PDF file (inside the bundle)
The icon
The name
4 Storyboard screens
As you can imagine it would be a nightmare to maintain 16 independent projects, my main concerns is that Features/Bug fixes in the main code will have to be applied 16+ times. The other thing is actually building and pushing 16 different binaries to the app store.
At the present time (Jan 2014) I want to know if there is a way to do this easily so that I only have to make a code change in one place and the 16+ other projects are updated and pushed to the store.
I have thought about git, or just having 16 projects and writing a bash script to do it for me but that seems dodgy. What is the most elegant solution to this problem that will reduce my overhead?
p.s. I don't want one app with 16 different icons/pdf due to size reasons
p.s.s. Please don't make as a duplicated, I want to know what solutions are there today, not a link to a slashdot question from 2010 :P
You could create a project for each app (so you won't have to change the project settings, e.g. name, icons, bundle identifier, ...) where you add the different PDF files and setup the storyboard screens.
Then you would create the classes in one project and drag & drop the files to the other project but uncheck the Copy items into destination group's folder option. That way you can change the code in any of the projects and it will be updated in all of them. You still have to build and submit each project on its own.
You can create one Xcode project file, with multiple targets. Each target in the project can have its own plist, icon, PDF and etc. Everything else will be shared and in one place.
We have a fairly rich e-learning app, built mostly using cocos2d. Currently we are in alpha and want to setup our project structure so we can also build a Mac version to target the Mac App store. It is about 80% cocos2d with some intitial screens in UIKit which will have to be ported to Mac (re-written).
What is the recommended setup for targeting both the Mac and iOS app stores from a single code base? I assume the choices are:
Create 2 xCode projects in the same application source code root folder and use each project to build a single target. This would be: Project.xcodeproj and ProjectMac.xcodeproj
Add a new Mac target to our existing iPad application project and then fiddle with target membership to get the desired results. This would be just: Project.xcodeproj
Further complicating the situation is that we currently use cocos2d as a static library for the iOS app. We also have a library called CoreInfrastructure that has a lot of code we use across all our projects. Recently I have figured out that I can create a project to simultaneously build a framework targeting Mac and a library targeting iOS from the same code base. This is done by starting with a framework project and adding a target to build a static lib for iOS.
So just wanted to get everyone's opinion and insight. Anyone know of any caveats to watch out for in the above choices? Anyone who is building for Mac and iOS app stores simultaneously care to share their structure? Adding a target worked on our library code ... is that the way to go for the application as well?
Are there any issues doing archive and distribution builds for either choice?
Thanks in advance.
WWDC session "Sharing code between iOS and OS X" answers all the basic questions in this topic. iWork team presented how they have got away with creating Pages, Keynote and Numbers with shared code base for both iOS and OS X.
The key for their project was using:
separate Xcode targets for iOS and OS X
separate project for the shared code in a form of a .framework
target dependency on the framework from the point above
I encourage to watch the video or read the transcript from this session:
WWDC 2014 Sharing code between iOS and OS X
ASCIIWWDC transcript
I recently used kstenerud's iOS Universal Framework to build a shared framework codebase that works for both iOS and Mac apps. I just needed to manually add a target for a Cocoa framework after I had created a project for an iOS framework. That way I can develop the sharable code once in the framework and link it in both the iOS and Mac apps. You can even make the framework contain UIKit-specific code for your iOS app and AppKit-specific code for your Mac apps. I wrote about it in my blog if you are interested.
For the applications use two separate projects. Using multiple targets for iOS and Mac in one project is very useful if they are sharing a library or framework. However, in your top level application almost nothing is shared. The UIKit code will need to be totally rewritten to use AppKit, the dependencies will be different, and even most of the project settings will vary.
Of course if you really want to see everything at once you can put both platform specific application projects and all the shared dependent library/framework projects in a single workspace. This is more a question of work style. If you want to switch back and forth between the two frequently this makes the most sense. If you want to simplify what you are looking at you can put them in separate workspaces that share many of the same projects. Separate workspaces has the disadvantage that a project can only be open in one workspace at a time so you effectively can only work on one at a time.
I just use multi-platform static library targets for the shared sources. You will need to expand that to the dependencies, however. If you have platform dependent implementations, you may want to create supplemental export libraries for those symbols.
So your structure might take this form:
CoreInfrastructure - cross platform static library.
PlatShared - cross platform static library.
PlatSpecific-OS X - OS X static library (or framework).
PlatSpecific-iOS - iOS static library.
The OS X app links to CoreInfrastructure, PlatShared, PlatSpecific-OSX, Cocos for OS X, and system libs.
The iOS app links to CoreInfrastructure, PlatShared, PlatSpecific-iOS, Cocos for iOS, and sys libs.
Problem (I've found) is, there are a lot of people who have not had much/any experience developing and maintaining complex project structures in Xcode. It's a pain (IMO) to setup duplicate targets, and properly maintain them as they grow -- even when they all refer to the same source files. That's why i prefer minimal targets and proper dependency structure.
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.