In my iphone app, I had initially divided the app into modules.
Each module was prepared as an individual xcode project.
Now I have integrated all modules by referencing and copying necessary files.
I want to submit it to the app store.
Will Apple accept this project which is comprised of different individual modules being referenced into one?
Is this is the right way of doing it?
Is there any better way?
Should I consider recreating the whole project into one?
Would different App delegates not be an issue if we do so?
Please Help and Suggest
Thanks.
When you submit it to the app store you submit a single .app binary and not an xcode project. Apple won't even know you're referencing other projects. It will just build all the files you need and compile it into the single binary.
Related
I am working on an iPhone application, latter to which i need to convert it into iPad application (Not universal)
I have seen somewhere a project that contains two separate xcodeproj file say
AppName_iphone.xcodeproj
AppName_ipad.xcodeproj
in single folder that are sharing common files, but opens as separate application when i double clicks *.xcodeproj files.
I goggled for doing same but i can't find good resources that shows how to do that.
Please suggest good way of doing same.
Thanks.
or try this i think that could help you http://developer.apple.com/library/ios/#featuredarticles/XcodeConcepts/Concept-Workspace.html
I currently have an app in the Appstore. I need to make changes to the app, but they are significant enough that we've decided it would be easier to create a new Xcode project from scratch rather than modify our existing project. I don't fully understand everything that goes into an iPhone application, just enough to support the code and make basic changes. But I assume that the binary I upload to the Appstore, to replace my existing code there, needs to be similar enough so Apples sees it as the "same" code. What things in the new project do I need to make sure are the same as the old project so Apple knows it's the "same" app?
I've compared the Info.plist file in both projects to make sure they're the same. I only needed to change the bundle identifier in the new project to match the old. Also, the Product Name has been modified to be the same. I don't know if these changes are necessary, but they are the sort of things that I think need to be the same. Are there others? If so, what are they?
The only thing that matters, as far as the app store is concerned, is the app id (Bundle identifier). You can rename the app, change the icon, upload an entirely different program, whatever. As long as the app id matches, the store considers it the same.
Other things I would check are the Build Settings if the defaults are not suitable or the Code is having issues compiling and the Build Phases and Build Rules for all your Targets.
Essentially if your Code compiles fine and you have no issues within the Application then the Bundle Identifier and the name (Basically the Info.plist) needs to be the same to replicate.
Edit: If you have migrated from an older Xcode version then you may have different Build Settings and Build Phases. I would just see if compilation is okay and the App works properly in functionality under all your Targets
The keyword here is possible. I know of a few resources that talk about this and how to create static frameworks - here: https://github.com/kstenerud/iOS-Universal-Framework and here: http://db-in.com/blog/2011/07/universal-framework-iphone-ios-2-0/
I'm interested to see if it's possible to create a dynamically linked framework in an app that will not be submitted to the app store. I know it's impossible to write to the application bundle on a device without jailbreaking it. Is it possible to say, download a compiled framework file, put it in the documents directory and then access it via the application (think plug-in architecture). I know that if it is, you would be turned away from the app store for submitting it, but let's say this was an enterprise app, or an ad-hoc distributed app where Apple would not have to approve.
In my initial research I haven't found anything supporting that it is possible, but I feel like this may be such a fringe case that no one has published anything about it. Looking for a guru to give me a definite "no" before I give up.
not sure if this is what you are after but according to Apple there dynamically linked libraries even usable in iOS - for example the system libraries... XCode contains copies of them and references them via symbolic links...
see near the end of this http://developer.apple.com/library/ios/#documentation/Miscellaneous/Conceptual/iPhoneOSTechOverview/iPhoneOSFrameworks/iPhoneOSFrameworks.html#//apple_ref/doc/uid/TP40007898-CH6-SW3
just an idea:
put the .dylib + include files you want to use into the respective folders where XCode expects the system libraries... use themn and then put symlinks into your bundle on deployment... let the symlinks point where ou copy the .dylib
I believe the answer is no. Apps on the iPhone are sandboxed. That is, aside from Apple supplied frameworks, an app cannot access anything outside of its own build.
This is possible now with IOS 8 Xcode 6.
According to the topic Using a Single Xcode Project to Build Two Applications, I should choose to 'Upgrade' the iPhone project to include an iPad. However, the page does not discuss pros/cons of Universal versus Two Device Targets.
I think the most desirable benefit of an upgrade is the 'single source' - write once run everywhere (unlike Java and its 'debug everywhere').
I would like to know the problems encountered in the field when using universal binaries versus distinct targets?
The most common reason to avoid building it as a universal app is if you want to charge more for the iPad version. A universal app has a single App Store entry. Building it as two separate apps lets you submit it twice, and set different prices for them.
The single/double App Store entry issue has a lot of ramifications - merged/separate reviews and ratings, release charts, promo codes, etc. They are essentially different apps from the App Store and end-user point of view.
I'm not sure what you are getting at with the "single source" point. Just because you are generating two app bundles, it doesn't mean you've got two copies of the source code.
I have split my iPhone app into two targets one for the ipad and one for the iphone. When I upload to the appstore I can only have one binary. But I have two targets?
I think I am missing a step. Thanks in advance for any help.
A "target" encompasses all of the instructions that Xcode uses to build your app.
You can have two targets inside of one binary, although this is not always done. This is how Universal Binaries are made. The two apps are bundled together inside of one binary. If you open up a Mac app "bundle" you will notice a few meta files, like icons and such, and there will be the actual compiled binary code. An iOS Universal Binary has both apps inside of it.
(If you watch your compilation carefully, you'll notice that Xcode actually builds your app twice. It does one build for iPhone/iPod and one for iPad.)
Provided that your Xcode project is set up properly, you will get the intended results.
The binary will be fine, the "targets" refer to what runs when it is run on an iPhone vs iPad. If the project is setup correctly for universal it should work fine.