This question is not really technical in nature but it is clearly answerable with yes/no and so I hope its fine if I ask it here on StackOverflow.
My scenario is as follows: In order to share code between iOS and Android I'm using C++ for much of the app's logic. I'm about to start writing network code for both platforms and I plan to utilize OpenSSL or one of its derivates (LibreSSL / BoringSSL) to be able to do HTTPS calls.
OpenSSL/LibreSSL/BoringSSL would be statically linked into my app and periodically be updated by releasing a new app version.
However, I'm unsure about whether Apple would accept such an app in its app store or not. As far as I know they take a closer look at what is inside the app and I want to prevent a situation where all code is written but eventually rejected when attempting to publish the app to the app store.
I'm looking for a clear yes/no answer whether Apple accepts such apps nowadays (2019). Preferably this answer is coming from someone who actually knows the answer i.e. from someone having done the same recently (2018/2019).
Did anyone recently succeed in publishing such an app into Apple's app store?
Not only does Apple allow this, that's exactly how one is supposed to use OpenSSL in an iOS app. The operating system doesn't provide OpenSSL for the apps, so the apps need to bring their own one.
You'll probably need to declare the use of encryption to comply with encryption export regulations. It is, however, required even when using the system encryption like TLS.
I want my app to make urgent security updates without going through Apple's review process. I am not trying to do this for all my updates, or circumvent Apple's reasonable review requirements. All it would have to do is push a .swift file to the client, which would be accessed somewhere in the app.
I definitely know there is a way to do it in JavaScript, as I already made a mechanism of the same type in a React Native. I used this approach, but I don't think there is an equivalent for iOS from what I've heard.
There definitely is a solution, as I've heard many devs doing this (for less, um... valid reasons) but I can't find it.
You cannot do this, for both technical and policy reasons. Apple expressly forbids you from delivering new code to your apps's outside of the app store process.
The other part of it is that your apps run compiled object code, not source code. Aside from the iPad Swift playgrounds app, there is no Swift compiler on the user's devices.
Javascript is a horse of a different color. That's an interpreted language, and is designed to be delivered and run dynamically.
I have a rather long app, about 20 pages and some of the code should probably be re-coded, my first app with Xcode and I learned a lot along the way. I could add a few objects to replace string arrays etc and make the code more readable. I was wondering if Apple looks at all the code when submitting to the app store or if they just want it to work with no errors. So I guess the question is ... should I 'fix' my code before submitting it?
I don't think Apple can access your code unless they can decode your binary app back to source somehow (It is very difficult to do that). They do perform some testings on your binary project (such as networking) and play around your app a little bit to check if your function provided is valid and works as described without any serious bug.
As long as your app works and does not violate any of the App Store Review Guidelines you should be fine, you can check the Review guidelines here to get more information about the review process and what Apple expects from your app.
I have never developed for iPhone, but I have developed an HTML5 web application.
I would like to submit to the Apple store a free app whose job would be to just open up the HTML5 webapp in the mobile browser.
Do you think it will be likely that such an app can be accepted? Can you please provide links or evidence?
Is it possible to ask this question to the Apple team so that I am not going to waste $99? If so, how?
If your app has native web views pulling internal HTML5 information, you might be able to sneak it by some of the app reviewers, but a good portion will say that there is not enough native Apple code in the app. They are sticklers for that.
I have, on a few occasions, gotten away with adding push notification, saying it HAS to be an app, and can't rely on users going to the website since they need push (even though I never intended on pushing anything out), but Apple has caught on to this.
Ultimately, you need to use Apple code in xCode, and you need to use a lot of 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.