What are the things to pay attention combinating SenchaTouch (HTML-JAVAscript) with Phonegap to get an App for the AppStore?
Which things are important to get such apps into the appstore without refuse?
http://developer.apple.com/appstore/resources/submission/tips.html
http://developer.apple.com/appstore/resources/approval/guidelines.html
In particular:
12.3 Apps that are simply web clippings, content aggregators, or a collection of links, may be rejected
Using Sencha Touch with Phonegap hasn't caused ANY problems for the app that i've developed. I got rejected once for not supporting both directions on display orientation (not only was it landscape only, it was only one direction of the landscape. Currently, it's landscape only and it's been approved many times).
It seems like you really ONLY need to worry about the same guidelines that you normally need to worry about. It feels weird having 100 javascript files and only a couple objective C files, but they dont' put up any fuss, and our wait times for approval were great.
Related
i want to release an iPad application to app store. in my application on dashboard there are six buttons and on tap they open six different screens. but among them one is disabled. User is unable to do anything with it. We just kept it in the app as we are going to implement that feature in the next version. is that fine? is there any chances that my app will get reject by app store guys because of this.
Any help would be appreciated. Thanks in advance.
As per my experience Apple will Reject your application saying that either you have to implement that functionality or you have to remove that disabled button.
it may be rejected based on AppStore Review Guideline:
2.9 Apps that are "demo", "trial", or "test" versions will be rejected. Beta Apps may only be submitted through TestFlight and must follow the TestFlight guidelines
it would be more reasonable to implement the functionality; or not showing such features which are not part of the application at all – none of those cases cause rejection.
Why don't you add like a simple alertView saying « This feature will be available in the next version, stay tuned ! » or something ? Would be a way better UX overall. Either that, or hide the button for now. Either way, don't let a button do nothing with no user feedback, this sounds terrible.
I don't think app store will reject your iPad application. You should use rather web view control(in Android) in which you can show any web page or something like that, if you want to provide the facility that after installation of your app, uses can get the updated details from it. Just give it a thought.
I was wondering if its possible to write an ios app that 'disables' other apps from opening?
For example, when I press the disable button on my app, I cannot open whatsapp for the next 15 minutes.
If that's not possible, could a workaround such as blocking all HTTP requests to a certain URL be possible? or even blocking (or turning off) notifications from certain apps?
I've also been wondering whether or not a security module might disallow such code..
Any help would be much appreciated!
None of the suggestion you made in your question will work on a AppStore app. Since the app is sandboxed it can not interact on the level you want with the system.
Your only possibility is to write an app for jailbroken devices.
There might be private API present as per your need but one thing is clear if you target for Apple AppStore ,it will be rejected due to its policy as aslo said by other person. Moreover ,If you still wana develop it you should go for it and there is Cydia which is a appstore for jail broken phone so you could upload your app and try to sell it off. Hope this info is useful for you.
I developed my first iphone app recently and would like to port it to an ipad. I've got a couple of related questions.
1) from what i've read, it sounds like creating a universal app will increase the size of the app that the user will download onto their iphone/ipad. is that right? my app is not small right now and i'd like to add some functions to the ipad version. Its something of a disincentive to package a universal app if it means a larger app for iphone users who won't benefit from the added functions added to the ipad app.
2) is it possible to have separate apps for the ipad and iphone but only make users pay for one version of them, if i don't go for a universal app? That is, if someone pays for the iphone version right now, i'd like them to have the ipad version for free when i finish it in about a month. is that possible outside of a universal app?
thanks,
rich
1) Yes, a universal app has everything for both versions so it is bigger. For a user that wants the app on both types of devices this isn't really a problem.
2) No, there is no way to have two separate apps such that the user can have both while only paying for one. At least it's not possible through standard means. If you make both apps free with IAP, then you could have your apps generate some sort of code that could be entered into the other to grant full functionality. Such a scheme is a lot of extra work.
Try to do a universal app and see how big it gets. All of the code is shared and as long as you don't have too many iPad-only full screen images or iPhone-only full screen images, the universal app isn't much bigger than a non-universal app.
I don't have a iPad, and [bizarrely] creating an iPad app (for the experience mostly) but I would like to put it on the App Store after testing it.
My cousin has an iPad, and possibly could lend it to me. Is there any chance of the iPad being broken by an app that doesn't go outside the App Store rules (no private APIs etc)? I know each app has it's own sandbox, and it can't "get out of it", but has anyone ever experienced a problem that couldn't be resolved by a restore from iTunes, or has anyone had to perform restore at all?
That way madness lies. In essence, lots of things can go wrong - you might drop the iPad into a carelessly placed vat of liquid nitrogen for example.
However, it's incredibly, incredibly unlikely that you'll in some way "break" the iPad by simply installing a provisioning certificate and test app onto it. (I won't say "impossible", as your computer might be struck by lightning, reducing all attached USB devices to a cripsy un-pleasantness the very second you first run the app.)
That said, if you're feeling paranoid, simply get the owner to back-up the iPad within iTunes before you borrow it. :-)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Can anybody help me out to know the possible reasons for which Apple store can reject or raise objection to submit any iPhone application.
Here are possible reasons (unofficial, from here):
Vibration. It is not permitted to use continuous vibration in your apps - short bursts as warnings is all that is allowed. Don’t bother trying to set up a timer to keep the vibration going, it will cause your app to be rejected.
Linking to private frameworks. This is obvious, but somehow in playing around with stuff we had linked to the MoviePlayer.framework. That’s a no-no, and cost us about ten days while we unlinked that framework, recompiled, and then resubmitted.
Improper handling of editing in tableview cells. Also obvious, but be aware that if you enable table cell editing, you’ll have to manually specify which cells should respond to editing controls and which should not. We had some random prefs cells in one of our early apps that were able to be swiped to bring up a ‘delete’ badge. Of course it didn’t do anything, but Apple justly considered this poor design and rejected our app.
Icons. Make sure the 57 pixel icon is identical to the 512 pixel version. Also, use a different icon if you are creating ‘lite’ and ‘pro’ versions of your app (i.e., free and paid). Using the same icon for both sends your app straight to … you guessed it … the bin.
Copying existing functionality. This one is much more subtle and insidious, and has probably affected the great percentage of developers. In addition to the widely publicized Podcaster debacle, reports from user comments indicate that Apple is casting a wide net when looking for duplicated functionality. Mini web browsers, or apps that essentially show web pages, seem particularly vulnerable, even if they add new and/or useful functionality. Stay away from email clients as well.
Using appropriate keyboard type. If your app asks for a phone number or other numeral-only input and you present a keyboard that also includes the possibility of entering standard alpha-numeric input … yep. (Thanks Jeremy1026)
Version numbers. If your app is currently at version 0.99 or below, you’d better consider giving it a promotion as Apple seems to prefer 1.0 and above. One of ours was recently rejected for being .016, with a message suggesting that our version number wasn’t even numeric. When we resubmitted the same app from scratch as version 1.0, it went through.
Network Reachability. If your app requires any type of network access you need to make sure it works when that access isn't available. If it doesn't it will be rejected. Apple provides sample code to test this which you can use as-is in most cases: https://developer.apple.com/library/content/samplecode/Reachability/Introduction/Intro.html
And last, but not least:
Flatulence Don’t even try. ;-) UPDATE: sorry, this seems to be outdated by now. Apple makes a lot of money now with "fart apps": see this article.
Edit:
Here is a link to a recent article about ten iPhone Apps That Didn't Make Apple's App Store.
And a tip: Apple has a Mac app called Application Loader that you could install. Once you install it, it analyzes your app's zip file. It verifies all the certificates, icons, and other things are correct before submitting to Apple. Using the Application Loader minimizes your chances of app rejection.
Another interesting resource: App Store Roundtable: Transparency and the Approval System (appleblog.com)
Yet another edit:
New rules by February 2010: "No Swimsuits, No Skin, And No Innuendo" (source: TechCrunch article, Wobble author's blog)
By the way: during the iPhone 3.0 preview event (march 2009), an Apple spokesman told that 96% of all submitted application were approved.
Apple have now (as of 9th September 2010) published their official list of app store review guidelines:
appstore approval guidelines
(apple developer login required)
or a mirror here:
app store guidelines
Will apple want to create an app like that in the future? If (yes) reject.
Do you have a really awesome idea that apple may want to use in the future if(yes) reject
Here's the video of the SDK announcement that describes Apple published list of rejection criteria:
SDK Announcement
As others have noted, Apple also seem to have a bunch of other conditions that they don't publicise. Note that rejection notices are now covered by the NDA.
I can't confirm this but it makes sense, but people are reporting their apps being rejected for being too simple or too trivial.
Just got a bounce for handling network outages badly. If you connect to the network, be prepared to handle any error conditions that may come up.
My paid version of app was rejected by appstore.
After Purchasing and downloading app first screen was "User Agreement" and when user taps on " I agree" only then he is able to continue using app.
Apple described the reason of rejection "when user purchased app from appstore and download in phone then you must not restrict user to Agree with Agreement" instead display your agreement before downloading app in iTunes.
Amazingly, apps can get rejected for trying to keep their interface consistent with Apple's own apps. (ie, using pinch zoom/expand gestures)
There is a site I know which can help you generate great advertising ideas with iPhone. see this site:
http://itunes.apple.com/app/adpack/id359562015?mt=8
I submitted a paid app to app store but get rejected and i learned another possibility of app rejection
My app was Game Center enabled. When app starts first screen was login screen that prompt user to login through GameCenter to continue.
They rejected the app giving reason- As user will not be able to get services of your app unless he is not logged in with Game Center although he paid you to download app. You cannot restrict user to login through Game Center each time before app starts.
From 1st May,2013 onwards if we don't support iPhone 5, your app will be rejected.So iPhone 5 support is must.