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.
Related
I have an app that has been released on the app store with separate versions for iPhone and iPad. Now I wish to convert the app to a Universal version but I have an issue which I'm not sure can be resolved.
Both versions of the app use a different bundle identifier (for example com.mycompany.app.iphone and com.mycompany.app.ipad). I want the new (universal) version to overwrite either of the old versions when downloaded from the app store. To complicate matters further, core data stored for that app needs to be retained.
I'm not sure its possible and perhaps the protocol is to release the universal version under a new bundle identifier and have users start again but if a workaround is available it would be really helpful.
your options:
1: Update both your iPhone and iPad apps with this universal binary (with respective bundleIDs and app names)
2: Create a way to sync data between apps by creating a web service. one of the apps I have used extensively - Gas Cubby, does this for transferring data from its free app to paid app. You could implement it in a similar way
3: Nuke one of the apps, update the other app with the universal binary
Option 1 is the easiest. 2 will take longer. 3 is dirty.
(will update this answer with more options if I come across any)
As far as I know and from what I've read before, you can't change the bundle identifier of an app published in the app store.
Due to the sandboxing, accessing the data of your old app from the new app is also impossible.
There are several ways you could go about solving this issue, depending on which one suits you best. You could create a new universal app, and abandon the old ones hoping that the users change their preferences, or you could be pushing the same update to both applications, essentially, having the identical app under two different names. I'm not sure what are Apple's stances on the second option, but it will be a hassle either way. Good luck!
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
I noticed that there are different requirements for each platform here. I was wondering if it's possible to build a single project but with multiple targets where each target is Mac OS X (something like a CD / install build), Apple Mac Store, and iOS device.
IfIi'm going about this the wrong way then I'd love to know! I mostly develop on the PC but with the state of the App Store I'd love to spread out as much as I can!
Keeping separate targets for the Mac app store and an independently-distributed Mac application is simple. You just need to ensure that your receipt validation code is conditionally included on the app store target and not in the other target; and your custom licensing scheme is included the other way round. Things get a bit more complicated if you target different operating systems in the two targets, but they're not insurmountable: you can test for the existence of classes or selectors at runtime to ensure you never call newer API on older systems.
By the way, it's also worth having separate Info.plist files for these targets. Partly because you don't need or want to include things like Sparkle properties in your app store target, but also because each target should have a unique bundle identifier. The app store does odd things when you have an app installed that it thinks came from the store but really didn't, and you don't want to risk your updater or Apple's trying to update the app deployed via the other mechanism. But that's not really about organising your Xcode project, it's a deployment issue.
For the most part, yes. All Mac/iOS apps can be written in Objective-C and the code is very similar. However, you must bear in mind that iOS devices have different screen sizes from the Mac and even from each other. That means that the input metaphor is different, and that the UI is different. While it is possible to do what you want, it's not advisable to just code once and compile thrice.
That said, I don't use Xcode 4 so I can't tell you about that. Of you are looking to do different builds for different devices, you will want to write your app logic and your input logic as separately as possible. Then, you create multiple targets, one for each build. You define compiler flags for each target. In your code you will use those flags to use the appropriate code for your build.
At least as of 3.2.5, this is absolutely not a problem. You won't necessarily be able to apply all of your build settings project-wide, but you can specify them on a per-target basis.
Just add the appropriate-type target (Cocoa Touch, Cocoa, etc.).
I have built an app for Apple's App Store, now I want to submit the app to the Cydia store. How can I do this? Should I just post the app.zip file built for the App Store to the Cydia store?
There are a few differences compiling your app for Cydia vs the App Store. Big Boss does a good job explaining the difference in his post:
How to Compile for Cydia Submission
You should check out iOSOpenDev. It incorporates a lot of Cydia tweaks, Theos, Activator and all kinds of other things into Xcode. It allows you to create a new (Cydia) tweak of your choice and you can even launch that tweak on your device from Xcode.
To submit an "App Store" app, you would need to make sure you adjust the user directories. Since you will install the app into /Applications, there will be no sandbox; no Documents directory dedicated to just your application.
You will also need to sign your app with ldid. This "fake" code-signs your application so it can run in iOS. To submit the app to Cydia, you would need to find a repo you are comfortable with hosting the app, like BigBoss.
Be careful though, submitting an App Store app to Cydia could potentially get your app thrown out of the App Store and your developer account revoked.
In terms of building an actual full application, I believe the development process is the same but the compiling and preperation of the binary is different. The provided link is a good resource
If you intend to make a tweak which hooks into existing Apple classes and methods then you need something like theos by DHowett, a good basic tutorial is here
u need to create a repo. or send them to MMi's collection
to make a repo read Saurik's Guide: Here
Or read the easier guide that MYI made for us at: Here
to submit a package to the MMI repo,
try the Developer Portal:
http://modmyi.com/mmi/
Some info regarding paid packages:
http://modmyi.com/cydia/cydiastorefaq/
Basically, all the content in your theme must be your own original work.
All the graphics / sounds must be created and owned by you.
If you have further questions, drop a note to the admins:
http://modmyi.com/sendmessage.php
Well first of al if your app.zip is the .app file found in the payload folder of a .ipa file, then disregard this next step. Anyway, open up app.zip, go to payload, and then take out app.app. Make the app.app app.zip. Now go to http://www.myrepospace.com/iDeb and upload your app.zip. Then when it's done, download your new .deb file.
Despite of the title you seem to ask about submission rather than (or in addition to) building. I'd consider this the one best reference:
http://cydia.saurik.com/faq/repositories.html
It is from Cydia itself and includes sschunara's links and other BigBoss references plus more.
I frequently find that I need to have a build on my iPhone which is my 'demo-ready' version which might point to my demo server. I also want a build that is the latest and greatest debug build that I'm developing with that points to my development server. Has anyone found a really simple way for me to install two apps that perhaps are the exact same code but point to different servers? Alternately perhaps I would have an app that was a few versions behind the latest version? Preferably I would use the same XCode project to build and install onto the iPhone.
You can add special build configurations for them that each use a different info.plist file. So, maybe for your demo, you have an info.plist named MyApp-Info-DEMO.plist and MyApp-Info.plist for the release.
Then you could add your server variable as an info.plist variable and look it up when the app starts. Or even just create a DEFINE statement in your new configuration that's something like SERVER=demo.myserver.com for the demo and SERVER=production.myserver.com for the live.
The most important part is to change the CFBundleIdentifier in the new info.plist. So in your demo, you could name it something like com.mycompany.myapp.DEMO and the real one might just be com.mycompany.myapp.
This will allow both versions to appear on the phone at the same time (the different CFBundleIdentifiers). Just remember, if you are using in-app purchases or server push notifications, you won't be able to do this without a separate, specific profile for both your real app identifier and your demo one.
You could create 2 different targets with 2 different info.plists and 2 different preprocessor defines (in the Build Settings for each of the 2 targets). Then ifdef on the preprocessor defines to select the server constant the compiler uses for each target.
Then make the product name and the bundle ID different in the two different target settings (so that neither the device or the Simulator will confuse the two app bundles).
With the current version of Xcode, you'd achieve this by changing the app's Info.plist file to use a different bundle identifier (and possibly also change the Product Name of the app in the build settings).
The upcoming version of Xcode, from what I've read in the prerelease documentation, has a feature that may simplify what you want to do quite a bit. However, since prerelease software is covered under NDA, I can't give you any details.