I've been looking at various posts of iPhone app submission checklists, to prep for submission to Apple, but they are either not thorough enough or maybe I'm missing something (or not finding the right checklists).
For example UIRequiredDeviceCapabilities seems pretty important, but it doesn't get mentioned much anywhere. Is this kind of thing considered too obvious? What other obvious things should I know?
Thanks.
I think it's because it seems more like a part of the design or development process, deciding what is required - at time of submission you should have that all hammered out and setting those values is more a part of testing than final deployment.
I think some of that is more conditional in nature, meaning a lot of times people don't need to use that particular key unless they want to restrict access to their app based on what device the user has.
This is the one I always went by in the past: http://developer.apple.com/news/ios/appstoretips/
But honestly, the most important ones are:
Make sure all the app meta data is filled out and you aren't using any trademarks/copyrighted items anywhere in your app
Make sure you checked your app for memory leaks and fixed bugs for crashing
Don't use other app names in your keywords
Make sure you have error messages
for network issues (or anything else
that might make a button appear like
it does nothing and would confuse
the user)
Answering my own question here:
"Here are some of the important keys that you might want to add to your application’s Info.plist file specifically for iOS:" (according to iOS programming guide). But from what I can tell only CFBundleIconFiles, and UIRequiredDeviceCapabilities are really required (unless you have no required capabilities in which case leave that one out I guess).
CFBundleIconFiles
*
UIStatusBarStyle
*
UIInterfaceOrientation
*
UIRequiredDeviceCapabilities
*
UIRequiresPersistentWiFi
Related
In my game, I'm planning to add IAPs for different level packs that the player will be able to buy and play in the game. But after reading documentations on IAPs, there's still one question I'm wondering : Is it better to download the new content from Apple's server, or unlock it in the game with NSUserDefaults?
The problem is that if I chose option 2, the content will be easily hackable, and the app will need an update for each DLC I'm adding.
And the problem with option 1 is that the new content will be downloaded in the Documents folder, but my app search the list of levels in the resource folders (I know it's not hard to implement, but I'm just saying the pros and cons)
Anyone can tell me which one is the best practice, and why?
Thanks in advance!
Well, I think both options are good. Whats the size of these packs? If you have numerous iaps all consisting of new levels, id recommend to have them downloadable, imagine shipping the app without the extra levels, quite a network-loadoff.
As you are stating, option nr 1 gives you the ability to add levels dynamically. This is convenient since apple are quite slow when it comes to uploading of new builds. Come to think of it, they are not super fast when it comes to revising your DLC either.
Due to the hacking risk and initial reduction of app-filesize, I would definately go with option one but if possible, i'd provide the actual content from a private FTP server. That way, the new content is available directly.
We've complete an app in iPhone. For the next version, we want to add skins/themes to the app. There are some good replies to similar posts that I read on stack overflow regarding this and different developers have given varying ways to solve the same. But anyone who's actually been able to accomplish this and get an acceptance from the app store, could he/she/they please post a solution to this?
You'll need to look into singletons. I don't know all that much about them, but they are basically information that any part of the app can access.
You would need to save the user's theme preference as a singleton, then in your scenes would need to get the information about the user's preference off that singleton, and run a method that would check what the preference was load up different background/images/sprites depending on that.
I have created one static library in iPhone sdk, and I am worried that If I provide code to anyone in which static library is being used, then anyone can use static library. So Is there any way to restrict them by using library until they get license? I am new to licensing any library.
This is a problem you must solve by legal means, not by any technical solution.
Make sure to only give the library to people you trust, and if needed have them sign an agreement not to spread it.
Also ask yourself if it is worth the trouble. Is your code so unique that they can not find it elsewhere, or duplicate it themselves in a few days, using Google and stackoverflow alone?
As said by #PeyloW,
This is a problem you must solve by legal
means, not by any technical solution.
But there are some simple ways to "block the code": You can create a RAR or ZIP archive, encrypted with password, and after they get license, you can tell them the password.
If you want to "Bind" license to a "developer's computer", than you simply need something that you can bind. For example that can be the emulator's UDID.
you can generate a license for emulator's UDID, and only limit emulator development, while allowing unrestricted access for ARM code (on device)
so you can basically check for emulator UDID
check license file
if license file allows that UDID, run
if not then show a message etc
for development purposes, everybody needs emulator, so I guess limiting it is enough for you.
Personally, I would create a new static library, check your code coverage and copy in only the code used by the app consuming it. Or in other words, don't give away more than you need to.
Then, as someone mentioned in the comments, obfuscate the calls. Your library is going to be worthless without documentation if your calls have to be deciphered. Odds are that anyone that has the aptitude of deciphering what your calls mean probably has 80% of a white-room reverse-engineering of your code already done.
You can't really force a license upon your client at the final hour unless they agree to it. So even if you did try to force them to license your library, it might not even be valid to do so with the original agreement intact. I'd do damage control to the extent your time is worth and chalk this up as a learning experience. 5 months from now, you'll probably have that static library re-factored to something better anyway. And next time, you'll work that into your agreement.
If you provide the static library, no one can get back the code.
Do you have reservations in others using your static library also?
My company is looking to develop an iOS application which would need to make use of private APIs to function - in fact use of such APIs is the entire basis of the program (I'm purposely not revealing details for business reasons).
My question is, is there any chance that if we explained the situation, that Apple would allow an exception for our app to be approved even when using these private APIs? I believe we have a very legitimate reason to request an exception for the functionality we're looking for, so I'd just like some examples of any exceptions that have been made to the private APIs rule with details so that we can have a better idea of what might be expected from Apple. Thanks.
I'll be honest with you: no. If you're looking to put this on the app store, no.
You may wonder how I know this with such certainty: I've worked with carriers that carry the iPhone, and I've worked with very large companies with whom Apple has working relationships (ie, you can actually talk to someone fairly senior at Apple). If Apple won't let carriers use private APIs, they not going to let you do it either. One 'legitimate' private API use might be to put recent call information into a carrier provided account app. Could be pretty useful, right? And the carrier already has this information, so no problem? No. It's a big problem. Apple just won't allow it. You have to get it from elsewhere (ie, via the carrier's own database).
There are no exceptions, and currently apps get statically analysed immediately after submission. If you call a private API your app will almost certainly be instantly rejected automatically by the static analyzer. It won't even go through manual review.
If you're looking to distribute on the app store, there are literally no exceptions now that code gets statically analyzed.
Put it another way: if Apple made an exception for your app they'd have to make an exception for every app. And then your unique selling point wouldn't be so unique any more.
Sorry I can't give you a more positive answer, but I speak from experience!
Its entirely possible, but extremely unlikely. they made an exception for UIGetScreenImage(); but that was because there was a very large number of developers who had filed radars for it.
I would suggest you file high quality radars for enhancement, explaining what you want and why. also maybe consider using a DTS to find out if there is an alternative way, or if they are able to get authorisation for it.
I'm scratching my head over this.
I have a moderately successful app which has a free "LITE" version in addition to the full one. This is a utility app, not a game with levels, and I'm having trouble figuring out what Apple will accept for the lite version. The reason this is now an issue is that I've brought both code bases together with different targets and my new improved lite version will be iPad compatible as well.
There are two fundamental differences in the versions. In the lite version, the data displayed is only displayed for the current day, whereas the full version allows users to choose any date. Additionally, one of the data screens shows 3 data points in detail, whereas the full version shows much more. The lite version is perfectly functional in its own right and has no greyed out features.
What I would like to do is use the spare space on the lite version data screen to explain that more data is available in the full version and offer a button to upgrade, however I can't figure out if Apple will classify this as "upselling" (well how else am I going to mention the full version?) and from reading the new app store review guidelines, I was disappointed to note that absolutely no further clarity seems forthcoming from Cupertino in this regard. All the examples I find from Apple are games with additional levels and this simply doesn't match a "utility" application.
Is there any recent advice on what is and what is not allowed? I'm aware of not having greyed out functionality and nagging the user - but does having an upgrade button on one of the tabs (in the case of the iPad in a popover) count as nagging? Am I allowed to mention the additional features in the premium version or does that count as upselling? If not, what can I actually say?
Clues welcomed!
Frankly speaking, there is no way to be 100% sure without submitting the app. There might be someone who have already tried this and get rejected. It's not very easy to be sure. But as a user personally I won't be happy to see the upgrade button in every page. Rather I would like to get the summery of full version in a different page. This might not be a better design to have an upgrade button in every page, though this is my personal opinion. Apple gives importance to be consistent with the convention, and the convention is to have different upgrade page, I think.
You can download a number of lite apps and check whether any one has done this kind of thing. The policy should be same for both game and utility. If after checking many you don't find a single one, then you should reconsider this. But yes, you can't be 100% sure.
The rules appear to be inconsistently applied.
I think it boils down to the perceived difference between "Ha! You don't get $feature unless you pay us!" and "By the way, we also offer $more_expensive_app with more features." The two are effectively the same thing, but they leave a different impression. Yes, it's a big grey area — I've seen apps across the spectrum (I don't recall any persistent nagging/mentions, but certainly "buy $full_app to get more levels").
"Other apps by $company" might be a good way to go, perhaps in an "about" tab or similar.
Reviewers are also far from consistent. Before Apple did any "private API" checks (they didn't seem to until mid-2009; apparently not even the frameworks you linked to which is dead easy), private API usage was determined by whether your app did anything in $list_of_suspicious_behaviour, which seemed to be applied inconsistently by different reviewers.
I've also used "$full_app" because that's the impression I got; I think part of the guidelines is that you're not supposed to give the impression that your app is not "full". I also hate crippleware (artificially limiting a feature, e.g. a navigation app limited to 8 waypoints and telling you to buy the full version if you want more, as opposed to simply not including a feature), but Apple doesn't seem to mind.
Apple allows ads in apps if they are presented in a reasonable manner.
Developers can choose which ad network to run, even from competitors such as admob.
There's nothing to say you can't be your own ad network.
Just make sure your ad for your products (which occasionally just so happens to be an ad for the full version of the same app) follows the same presentation rules as the ads for admob, iAd, etc. follow. Your own ad network may or may not be the campaign you choose to run during the review period.