I have released an app in the appstore months ago.
It was first made only for iPhone (because I wanted to do so), now I would like to release it also for the iPod Touch.
What I have to do to make the iphone app available to ipod touch too?
When I update the app (new version tested on the ipod) I cannot change the value of the dropdown labeled "Device Requirements"
I don't want to make another app with the same content and same code just to change that value!
Many thanks
I would contact Apple Developer Support and tell them you would like the change. In many cases, they can override things like this.
This is weird. Anyway, besides contacting the support, bear in mind that you also need to modify your -info.plist file adding the "Required device capabilities" (UIRequiredDeviceCapabilities) key.
Basically, you define here what kind of hardware your application uses, such as wifi, core location, compass, accelerometer etc. This is then used to automatically distinguish a device capable of running your app from another which is not.
This is not yet mandatory, but Apple will warn you if you submit an application targeting the iPhone and iPod Touch 2nd generation without a properly configured plist file.
I've come to a solution releasing an update of the app.
Related
A further question about Bluetooth and iPhone.
Is it possible to discover nearby "non-ios" devices via bluetooth programmatically? The device uses the Hands-free-Profile. When I go like "General > Bluetooth > On" it works fine and I can pair with it. And thats exactly what I want to do but in my own App. I know the official SDK doesn`t support it. So my questions are:
When I`m member of the "Made for iPod"-Program, will I have access to the Hands-free-Profile API?
Important: The device already exists and I have no influence on it. So no possibility to implement
a special ship or so.
Another opportunity I found is the Private Framework BluetoothManager.h. Is it possible to
discover/pair the device with an iPhone?
In one sentence: I want to build an app that exactly does what the Bluetooth-function in the iPhone settings does. Possible?
Thank you
I want to build an app that exactly does what the Bluetooth-function in the iPhone settings does. Possible?
No, it is not possible with official APIs, even if you are a part of the Made for iPhone program.
In one sentence: I want to build an app that exactly does what the Bluetooth-function in the iPhone settings does. Possible?
A preliminary search didn't find the official rule about it, but Apple specifically forbids apps that duplicate the functionality of their built-ins. So, no, your app will almost certainly not get approved.
And I'm pretty sure the T&C forbid interaction with non-Apple-approved devices, but I'm not sure whether they strictly apply that to bluetooth things.
Yes , using the bluetooth private APIs. You can get a list of remote devices, each a BluetoothDevice object, and use the afferent methods to pair or connect.
I want to update my app to make use of the multitasking functionality and local notifications available in OS4. My question is, if I update my app and make it only available for OS4 and above does this mean that if someone is running OS3 on their phone they won't get the update? or they will get a warning that they need to update their OS? What I don't want to happen is for them to update their app to find it no longer works? If the final situation is what will happen, how do I write the code to find out what OS is being used?
Thanks
If they try to update on the device, then they won't even see an update that doesn't run under their OS version.
However if a previous customer updates their apps using iTunes on their Mac or PC, then iTunes may show them any new update. If they download that, iTunes will blow away its copy that is compatible with their current device/OS combination. The new copy shouldn't overwrite the working one on their device. But if the user ever needs to do a restore, or deletes the app and wants to reinstall it, they're probably out of luck unless they have really good backups and know how to use them.
If you update your app to be 4.0 only, and also mark your app as 4.0-only in the Store, then people will not even see your update.
You can have the best of both worlds by designing the app to use 4.0-specific features only on 4.0 devices. Weakly link 4.0-only frameworks, and in your code use [object respondsToSelector:#selector(thisOnlyWorksInOS4:)] to test for 4.0 features before using them (or, in the case of multitasking, use the multitaskingSupported property of UIDevice, since not all 4.0 devices support multitasking). Alternatively, UIDevice also provides a systemVersion property.
This blog post explains these techniques fairly well, including weak-linking frameworks: http://blog.federicomestrone.com/2010/07/18/base-sdk-deployment-target-weak-linking-and-import/
I started building a Universal app and it turned out the design doesn't work well with the iPad, so I've decided to make it a stand-alone iPhone app instead. By that, I mean I'd like the app store to see my app as an iPhone app, not a Universal app. I was just about to create a new project and move my existing iPhone code over to it and it's a ton of work because I had existing Core Data stores and other files that require some labor.
Is that the route I should take or is it easy to convert my existing Universal app to a stand alone iPhone app? If it's easier to convert it, what do I need to do?
I was exploring the Build settings of my project (I don't know what most of them mean), but I see the "Targeted Device Family" setting. Am I fortunate enough that I could simply set this to "iPhone" and that's the end of it?
Thanks in advance for your help! I'm going to continue looking into this now...
UPDATE: I found that all I needed to do was set the "Targeted Device Family" build setting to "iPhone". Seems to be working fine so far.
I believe that ends up setting the UIDeviceFamily key in Info.plist, which should be what the App Store looks at. You might still have a bunch of iPad resources floating around, but I wouldn't worry too much about that.
Curious what practices people have learned before making their final build and submitting to the App Store? Aside from switching from Debug to Release & commenting out calls to NSLog what other basic and/or not so basic things should we be watching out for?
This is a good question and I'd like to restate some of the answers and add a few of my own. I've made this answer Community Wiki, feel free to add to it.
Delete the app from your device, turn off WiFi, off cellular data, now install and test app. Does it work properly (as much as it can without Internet)? Does it at least tell the user that a network connection is required (if it is) or does it crash?
If you use CLLocationManager: Delete the app, fresh install and run, but do not allow app to have Location Data. Does the app behave well or does it crash? Does it at least tell the user that it can't run without location data (if that is a requirement)? Does it work on an iPod Touch that does all geo location using WiFi only?
Run the app in the simulator and for each view controller do the following steps: (a) From the iPhone Simulator menu select "Hardware" --> "Simulate Memory Warning", (b) now navigate around your app to other view controllers and see if everything is working, (c) repeat test for another view controller.
If you support older firmware (ie: iOS 3.1.3), install your app on a device running 3.1.3 and test it there (if you don't have one, use the 3.2 simulator).
Start your app while on a phone call or when Personal Hotspot is active. Are all the screen layouts correct (the status bar is 40px high instead of 20)? Did the bottom 20px of the view get pushed off the screen or did it resize correctly?
Accept a phone call while in your app, does it resign active and resume properly? Do sounds from your app stop playing while in the phone call?
Start your app while playing music, does the music continue to play? Do your sounds mix properly or fade the music appropriately?
Test performance on a slower devices with limited RAM such as: iPhone 3G (128MB RAM, 412Mhz CPU) or iPod Touch (1st or 2nd gen).
Run the Clang static analyzer and fix (or at least understand) every warning.
Make sure NSZombiesEnabled is NO in the environment variables (caution: not sure if this is still a problem)
A few things:
I actually recommend not creating a build configuration called "Distribution" as Apple specifies, because I often am creating ad hoc builds for beta testers. I create two build configurations, one called Ad Hoc and one called AppStore, so I'm not confused. The only difference between the two is the presence of the Entitlements.plist file for the Ad Hoc build. This way I can test as closely as possible what I will be submitting to Apple.
Most developers are optimists. That's why we are working weekends to create an app that we just know is going to make us a millionaire. Before submitting though, be a pessimist. Imagine everything that can possibly go wrong, and double check it.
Don't assume anything. Don't assume that that tiny little change you made to the app won't affect anything else. Murphy's Law says that that tiny change will cause your app to crash on all iPod Touches or something. Test, test, test thoroughly between the final code edit and Appstore submission. If you have to make a tiny change, then repeat until it's perfect.
Remember that if the app doesn't crash for 99.9% of your users, then 1 out of every 1,000 downloads will result in a 1-star scathing review.
I use Clang static analyzer, Leaks and Object Allocations during development, but I do an extra run of these tools before submission just in case.
If you don't have an older device, get one, because the 3GS performance is significantly better and you may miss some important performance issues.
Test your app with the following configurations when network or location are applicable:
iPod Touch
iPhone 3G
iPhone 3GS
iPhone in Airplane mode
iPhone with Wi-Fi
iPhone with EDGE
Call the phone while using your app
Instead of switching to Release, I switch to "Distribution". It's a copy of Release, but that's is how I got taught by some Apple doc and iPhoneDeveloperTips.
Important points:
After the final build, but before you rush off to zip up your app, open the bundle using the Finder's Show Package Contents. Due to some bug in the MacOS, which bit me in versions prior to Snow Leopard (and it might still be there), if you zip up too fast (using the Finder's Compress or Archive menu item), some of the resources have yet to be flushed out into the file. When you do a Show Package Contents, the contents get updated. The way you would notice this problem is that the size of your compressed app would be between a fifth to a tenth or less of the expected size. You might think to yourself, "hey, that zip utility really does a great job of compressing", but that's not the case. This problem would occur at this point instead of during testing mainly because you are doing a "clean all" build and all the resources and contents of the app bundle are starting out empty and then being filled by Xcode. And for some reason, even after Xcode is done creating the file, the contents are still not actually there, if you compress, but would be there if you looked at them (sort of a reverse Heisenberg). Beware.
Another area I spend a lot of time on is to make a nice backup of the sources, after I have committed all the latest changes to SVN, made a new branch, and tagged the file. I also like to have my version number match my SVN build/commit number so I always know which SVN version matches my release. I have those two version numbers in my info.plist and can be pulled up by the app user when they hit i for info. For example, a current info.pist includes:
<key>CFBundleShortVersionString</key>
<string>2.0a1</string>
<key>CFBundleVersion</key>
<string>346</string>
There are different thoughts on how to use the CFBundleVersion. This is my way. Also useful is the command line utility, agvtool.
Once the app is built, after compressing so you're not actually making any changes to the compressed version, go check the app file and make sure it is signed with the right distribution cert and not your adhoc one. Learning to use the command line utility, codesign, is helpful for this kind of checking and debugging. By making the compressed copy first, you ensure that you're not in any way going to change the final copy that Xcode has handed you and that you will upload to itunesconnect, if all looks well.
Other things to remember are the app icon, the various other icons and graphics you need for the iTunes store, the info.plist, and the fact that when the uploading of the app fails with a cryptic error message, it usually has to do with one of these pieces being missing from the compressed file you are building (those pieces that belong in the app bundle).
Look into this check list document # Github
https://github.com/bapu/AppReleaseCheckList
Does anyone knows how to change the iPhone settings from interior of an app? For example: close the WiFi, disable 3G, change the sound volume and so on?
Apple is changing settings trough an app: Settings.app. It means that it's possible, I just don't know how.
Apple can do it in her Settings.app indeed.
Because of limitations of the iPhone SDK, some API's are not made public so you can't do everything Apple is able to do within her own OS. However, you can let the user adjust the main volume from your application, using the MPVolumeView class.
All applications written with the public SDK are sandboxed. They only have access to the properties and data which Apple deems feasible to use within that sandbox. Some of the examples you list are possible and some aren't.
Apple can perform these operations within their own applications since they don't use the public SDKs to write their applications - they use an internal SDK which has more functionality than the external one. They're not too worried about Apple employees hacking the phone and getting all your data off the phone.
Most of us wish that Apple could migrate more things to the public APIs (and they often do) but the reality is that the sandbox environment is carefully guarded. I wouldn't hold my breath to expect Apple to move all your examples over. You could always file a radar bug and let them know what you want - it's one way to have your voice heard.