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.
Related
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?
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.
Android has very good tools for creating different variants of an app (for example, the exact same code but with a different logo). You just create a different flavour and put a different image for each flavour's directory. How do I achieve this in Xcode? The information I have found on the web is very bad. I tried creating a new target for my project but that created a new storyboard, AppDelegate etc. It just created a new app altogether. I want different resource folders for different brands of the app. I'm using Swift.
You're not likely to get the same kind of setup you could have with Android. There are a bunch of features you could use individually or in combination. rmaddy's comments are good. Another option is creating additional schemes and setting the properties of the project for each one. The important thing to keep in mind is that the simplest solution may not look the way you're expecting.
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
I have an iOS game app that was created in Cocos 2D & Box 2D by an outside developer where I need to make some minor UI modifications (nudging platforms, item positions, etc.).
Normally, to get a visual view of the app in previous versions of Xcode, you would go to the .xib file. In Xcode 5 this is supposedly replaced with main.storyboard. Though I can build & run my project in the simulator or as an .iap file on my device, I cannot figure out how to make corrections to graphics (re positioning) as I would normally do. The main.storyboard file doesn't exist in my project.
Current file extensions represented:
.h, .mm, .cpp, .cmake, .pch
Thanks in advance.
Most cocos2d apps position "graphics" in code. Storyboard and xib files are not used at all for visual layout of cocos2d elements (nodes).
At best you'll find ccb or ccbi files which would indicate that CocosBuilder was used to design the scene's layouts. If there are no such files, you have to look into and modify the code.
If it was created in cocos2d/box2d, there are any number of ways that the presentation could have been created. Usually these don't involve storyboard/.xib files for cocos2d/box2d.
All the files you listed are standard code files; I don't see any graphics files (.png, .pvr, etc.) or physics editor files (.pes) in your list, or CocosBuilder files (ccb/ccbi). There are probably more file extensions in your project that you may want to find. You could potentially list out all the file extensions in your project, and maybe somebody on SO will be able to help you identify the tool or tweak the code by posting it.
However, I think the best option is to find a developer familiar with these technologies, let them take a look at the code, and get you back on track.
You may type a lot into SO and wait a long time for an answer to something a good developer could find for you in a few hours. If this is an academic (no commercial project), they may do it for free. Or for a nominal fee for a commercial project. Or for good will. Or the fun of it. etc.