Suppose I have a complete "app framework" I use for different customers. What is different for each is a config file (e.g. where to download new data files), data files and style files (e.g. background image and launch images)
I could of course
Copy code files around to different app folders replacing old ones.
Copy data/config/style files in/out of a single directory.
Use targets (just read up on these, new to xcode) - but does that work well with different asset folders, launch images etc?
Is there a better way? Somehow make a skeleton app / library that each specific customer app then inherits from? How about storyboards etc?
Only thing each customer specific file would change would be all the plist info, ID, launch images, data files etc. The code would be completely unchanged (I expect the skeleton app can handle whatever small nuances each customer will need, but far most is handled by config files. However, should the need arise, it would of course be nice if I could have cusomer specific code and visuals in each customer app, but this is not a requirement from my POV)
From what you're describing using targets is your best bet. So for example you'll have 5 targets in one worksapce, each target is a different app, all are using the same global.framework, each target got her own config.h \ config.m files
Related
I am trying to figure out what would be a good way of setting up application architecture and how to setup Xcode project itself, in the case where I have one base application, and I need to make multiple applications of it where the all apps will have those same base functionalities but will differ in a way that:
Assets may be different
Some features can be added ( new screens that uses new endpoints that are not defined in base app)
Localization can be differ (eg. one app can only be translated to english, and other can support multilanguages)
and probably some more, but you get an idea of what kind of an app (kinda template app) I am referring to.
What would be a preferred way to implement something like this? I guess targets and making a framework for a shared code is one way to go? Or there is something else that would be suitable too?
Target is a good start. Thanks to target memberships, you can "share" storyboards, source files and whatever you want between several targets. Then within each specific target, you add your assets and specific functionalities.
Frameworks can be also a good way to share functionalities between apps. But you can start and try simply with targets, and then later factorize code within frameworks.
The way I would do it could be this way :
Create your project with a single target, let's call it "Blank App"
Develop functionalities and prepare generic assets for this app
When you want to add a new App, duplicate the "Blank App" target, remove membership of default assets, add new ones, add also specific source and resource files, and that's it.
After a few targets, you can spot what can be factorized within frameworks. Add a new framework target, migrate your sources in it, make all apps use this framework, and you'll have a nice system.
I have this needs.
I developed an app and I want to duplicate it. I can copy and paste the project but if I do this 10 times can be a problem. The problem is, if I found a bug in the 10th duplicate, I have to review all other projects and I don't want to do this.
There is a clean way to solve this problem?
In other words, I have only one big code. The differences between the apps that I have to deploy are:
Launcher icon
Domain of the HTTP request
Package name
Splash Screen
App name
Some integers inside the app
Some assets
In Android, I do this with gradle, in particular, with the flavors. How I can do the same with Swift?
Create a single project with multiple targets. Each target would have a different info.plist and whatever other changes you need, but shared source.
I would do this with Git:
In your origin repository, prepare your project with placeholders:
Try to make a file where you define constants for the domain, the integers you mentioned etc. That file you could call Constants.swift.
Put all assets you need to change in one .xcassets. (a different one than the assets that will stay the same) For example the Icon. You can already add the image-sets you want to have in your apps, but leave them empty (or alternatively add placeholder images)
Write a placeholder for the app name and package name
create a default splash screen (I guess you mean the launch screen). This could either be empty or if you want it to be similar in all apps, prepare it a bit so you don't have to change much for each app
When you have committed and pushed your main project, create forks for each of your apps. In the forks, you can change everything that you have prepared as placeholder.
If there is a but somewhere, fix it in the origin. Then you can merge the changes easily to each of your forks.
Here's my setup:
(1) Create a new project of type Framework.
Move all shared code - extensions, subclasses, image assets, even .xib files - into a this project. I created an App/Bundle ID ("com.company.framework") but I'm not sure if it is necessary for App Store submission. Also, checking off the "Allow app extension API only" will remove the warning you'll get.
For files like images or text files, create bundles and drag the bundles into the framework. I've found you can add new images/files through Xcode. To retrieve them, here's the code:
public func returnKernel(_ named:String) -> String {
let myBundle = Bundle.init(identifier: "com.company.framework")
let kernelPath = (myBundle?.path(forResource: "cikernels", ofType: "bundle"))! + "/" + named + ".cikernel"
do {
return try String(contentsOfFile: kernelPath)
}
catch let error as NSError {
return error.description
}
}
(2) Create a second project, this time for your specific app.
Let's say you called your framework "Kernel". All public declared code is available by adding:
import Kernel
Now, here's the best part (for me): you have two ways to work with this setup.
(3a) Drag your framework .xcodeproj into your app project.
PROS: You can (a) make changes to your framework source code and (b) build both at once.
CON: You can only have one app project open at once because Xcode detects that the framework project is open.
(3b) Drag the Kernel.framework project into your app project.
PRO: You can have all your apps open at once.
CONS: You will need to (a) make your framework source changes in it's project, and - I think - (b) manually update every app with the rebuilt framework.
I say "I think" because I use the former set up. It's a small price to pay to have one app open at a time. Typically if you are making a framework change it's for a single app.
FINAL NOTES:
Changes made to the framework while working in "app #1" will be picked up when you open "app #2".
I have separate Git repositories for (a) each app and (b) my framework, both locally and on GitHub. Works perfectly.
I have separate Bundle/App IDs (and versions) set up for (a) each app and (b) my framework in the Developer Portal.
Come App Store submission time, I archive the app and upload it. The framework comes along for the ride.
I want to make multiple apps which share the same structure and code, but have different images, fonts, names and urls.
I would like a simple way to make this apps without replicating the whole project, so that when I find a bug I'll have to correct it only once.
Thank you.
PS: It isn't important the language (Objective-C or Swift)
Create multiple targets within the same project. You can then include or exclude asset catalogues, configuration JSON files etc. on a per-target basis. If you're consistent with the names this should get you most of the way there. You can also look at target-specific build flags or constants.
I'm pretty new to xcode and apps so got some source code and am learning by 'playing'. I've been changing some file names and now my images won't load.
I have:
[CCFileUtils setiPadSuffix:#"-ipad"];
[CCFileUtils setRetinaDisplaySuffix:#"-hd"];
which works for all the other images in the source code but the ones I have changed are not being searched for with '-ipad' appended to the file name. When I create the files and add them without the suffix i.e. image.png rather than image-ipad.png they are loaded normally. I want to have the suffix naming convention though.
I have checked the files are named correctly (no rogue capital letters etc)
I have loaded them into the project (copy items into destination group folder, and create groups for any added folders)
I have checked that the files are there in copy bundle resources in the targets build phases.
I've also cleaned/build/relaunched etc many times including deleting the app from the sim and also full computer restart!! Any ideas?
OK folks I've managed to solve this one after two days of painful brain wracking! Whereas most of the images are used interchangeably across the app, some are used for specific levels. The files are named the same i.e background.png but level1/background.png might be different to level2/background.png
There are sections of code that specify specific folders by using a custom getFullPath method written in.
Due to this, instead of images being loaded into the project in groups they needed to be loaded in with the folders being references (Blue folders not yellow).
I finally figured it out by looking into the Library/Application Support/iPhone Simulator files that were being generated.
Also its worth noting that I had to have both sd folders with no file appendices available as well as the -hd.png, -ipad.png and -ipad-hd.png files that were being used as well. So even though I was running on the ipad sim I had to have the iphone sd files available too.
Hope this helps someone in the future!
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.