Documentation

If your app just plays a song or video, displays a brochure or just one story, then it’s considered too simple to justify it being an app. Apps shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.

Apple says: “Apps that are simply a song or movie should be submitted to the iTunes Store. Apps that are simply a book should be submitted to the iBooks Store.”

There is one type of app that can offer ‘only’ content. This is a news or magazine app. This is accepted by the App Store but any other type of app has to bring an extra value to the user. You can’t just make an app of a brochure presenting your product. You could present different products, with extensive technical information, with interactive presentation features. You could also offer extra services in your app.

Always ask yourself why you would like to have this app on your phone/tablet and what it would take to make you use it frequently. If you don’t, you’ll understand why your app may be rejected.

This is about the same as the previous item. Mobile is an interactive medium. Users expect interactivity. Slide shows, video and audio content. You should add services, things users can do with your app, that make things easier for them, more convenient. Things unique to the medium.

Before defining the navigation and browse pages of your app, we invite you to first check Apple’s Human Interface Guidelines. They’ll provide a good baseline on how to design your user interface properly. Also understand that the term user interface is a broad  concept. The layout of supporting materials related to content are also important.

Apple and your users place a high value on simple, refined, creative, well thought out interfaces. They take more work but are worth it. Apple sets a high standard. If your user interface is complex or less than very good, it may be rejected.

“Your app should include features, content, and a UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or app-like, it doesn’t belong in the App Store.”

You are creating a native iOS app, not a web app. A native app is about offering an app-like behavior that supports the functionalities of the device. It is not about a click behavior of a website.

There is a huge difference between a web app and a native app. A web app offers a web experience. While you can create a web experience within a native app, Apple may reject this because there is no added value for having an app if it is ‘just’ a website. 

That doesn’t mean you can’t have any web content in your app, on the contrary, you can combine both if it adds value, but you shouldn’t create an app with only web content or an app that is just a copy of your website.

Imagine you create travel guides, and for each travel guide you create a separate app. Well, Apple will get back to you and ask you to combine all those guides in one app. You might think you’ll get less exposure but on the contrary. Offering an answer to far more search requests you’ll get a better ranking and it will be easier to create brand awareness.

If you have different similar apps or are submitting different similar apps, Apple will always ask you to combine them in one app because it just offers more value to your users and to yourself.

It’s a clear requirement that all apps submitted to the App Store have a privacy policy in place in order to get approval.

You need to:

• provide a link to your privacy policy statement 
• provide an explanation of your data retention policies
• enable users to withdraw consent to data collection
• include a direct link to Support along with contact information

It’s very important that your app only requests permissions that it needs to function. This includes permission to send push notifications, to use the device camera, GPS, the user’s location and more. If your app requires location services, it is important to explain why your app needs access to it.

“Apps that contain false, fraudulent or misleading representations or use names or icons similar to other apps will be rejected.”

Apple requires apps to be unique with their names, icons or interface and discourages imitation of any other apps.

In particular, Apple is very sensitive if you get tempted to use buttons or user interface components in your app that are theirs.

Also, don’t mention other supported platforms: if you have an Android app, that’s fine, but don’t promote it in your iOS app.

Apple doesn’t take too kindly to apps that contain explicit bugs or cause full-out system failures. If your testing of the app shows an unstable performance and ongoing crashes, get that fixed first before submitting for review. Otherwise your app is almost guaranteed to be rejected. 

Using the Twixl app, you can check all the functionalities of your app without having to build it first. That’s the first and most convenient step. After that, we advise you to create an ‘ad hoc’ build and to test it with some colleagues, and preferably some external people that weren’t involved in the development. If everything works fine, then you can submit your app to the App Store.

You can also have a beta testing team and define what needs to be tested. It is recommended you submit an update of your app at least 4 times a year, so it is important your testing process is clearly defined, so it can easily be repeated.

One of the most frustrating things for anyone on the receiving end of an app and in this case for Apple’s review team is to find placeholder content still in there. The same thing with demo content or beta content.

This is a sign that your mobile app is incomplete and wasn’t ready to be submitted yet. It will also give reviewers an extra reason to dig deeper and maybe find more things wrong with it.

If you need to use such content during the development process, make sure it is extremely well recognizable during testing so you can replace it by the real content before submitting your app.

Per Apple’s guidelines, your app must work on all the latest systems; i.e. hardware and software. It is important that apps run on all types of iPads and iPhones, at least if your app is ‘universal’, so keep that in mind for your tests.

Apple also recommends apps support split-screen usage, which Twixl will offer with TP11.

Twixl will always make sure to support the latest Apple software and hardware, so this is more an issue for Twixl than it is for you, unless you forget to update your app regularly. If your app has not been updated for a long time, you could get into a situation where Apple will come back to you and ask you to update your app, and if you don’t, it could even be removed from the store.

If your app takes payments to unlock functionality or allow the user to download digital content, transactions must go through the official Apple in-app purchasing system.

This goes for both individual in-app purchases and subscriptions.

This rule also applies to web pages linked to from your app.

It makes sense that If you want to distribute your app in Apple’s App Store, the least they’ll ask is that any transaction in the app will make use of their system. They have a responsibility towards the buyer because they are the marketplace.

As a publisher you can still sell subscriptions in your web shop and work with entitlement to provide access to your content. But within your app you can’t link to any external transaction platform.

A major requirement for apps in the App Store is that they have the metadata. That means including screenshots, descriptions, etc.

The main problems that can occur with metadata are:

• incomplete submission form
• incorrect or insufficient description
• not providing a demo login account
• outdated contact information
• missing or incorrect imagery
• inappropriate rating
• unrelated keywords

In relation to the screenshots you need to submit at least 3 different sizes, iPhone 5,5”, iPhone 6,5” and iPad 12,9”. If you don’t have the required devices to create all these screenshots, note that you can always make screenshots in the iOS simulator.

Be very careful with the amount of data your users need to download before they can get access to your app. If it takes over 15 seconds, your app may be rejected.

Therefore you should never use our ‘full offline mode’ on apps you submit to the App Store.

Offline mode is for in-house apps, as you are then in an environment where you are fully in control.