Including under which circumstances applications are rejected, and how much of a percentage Apple takes (widely distributed as 30%, though I can find no mention of it on their site).
Thanks!
Here you go: http://i.imgur.com/MgyH2.jpg
To be serious though, Apple has not published a definitive guide to the acceptance policy. It sometimes seems arbitrary and unfounded and even sometimes contrary to what they have provided as their pseudo-policy.
From the iPhone developer agreement section 3.3:
Any Application developed using this SDK must comply with these criteria and requirements, as they may be modified by Apple from time to time:
APIs and Functionality:
3.3.1 Applications may only use Published APIs in the manner prescribed by Apple
and must not use or call any unpublished or private APIs.
3.3.2 An Application may not itself install or launch other executable code by any
means, including without limitation through the use of a plug-in architecture, calling other
frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in
an Application except for code that is interpreted and run by Apple's Published APIs and builtin
interpreter(s).
3.3.3 Without Apple’s prior written approval, an Application may not provide, unlock or
enable additional features or functionality through distribution mechanisms other than the App
Store.
3.3.4 An Application may write data on a device only to the Application's designated
container area, except as otherwise specified by Apple.
User Interface and Data:
3.3.5 Applications must comply with the Human Interface Guidelines and other
Documentation provided by Apple.
3.3.6 Any form of user or device data collection, or image, picture or voice capture or
recording performed by the Application (collectively “Recordings”), and any form of user data,
content or information processing, maintenance, uploading, syncing, or transmission
performed by the Application (collectively "Transmissions") must comply with all applicable
privacy laws and regulations as well as any Apple program requirements related to such
aspects, including but not limited to any notice or consent requirements. In particular, a
reasonably conspicuous visual indicator must be displayed to the user as part of the
Application to indicate that a Recording is taking place.
SDK Agreement Page 5
Location Services and User Privacy:
3.3.7 For Applications that use location-based APIs or that collect, transmit, maintain,
process, share, disclose or otherwise use a user's personal information:
You and the Application must comply with all applicable privacy and data collection laws
and regulations with respect to any collection, transmission, maintenance, processing, use,
etc. of the user's location data or personal information by the Application.
Applications may not be designed or marketed for the purpose of harassing, abusing,
stalking, threatening or otherwise violating the legal rights (such as the rights of privacy and
publicity) of others.
For Applications that use location-based APIs, such Applications may not be designed or
marketed for real time route guidance; automatic or autonomous control of vehicles, aircraft,
or other mechanical devices; dispatch or fleet management; or emergency or life-saving
purposes.
Applications may not use any robot, spider, site search or other retrieval application or
device to scrape, retrieve or index services provided by Apple or its licensors, or to collect
information about users for any unauthorized purpose.
3.3.8 Applications that offer location-based services or functionality must notify and
obtain consent from an individual before his or her location data is being collected,
transmitted or otherwise used by the Application.
3.3.9 Applications must not disable, override or otherwise interfere with any Appleimplemented
system alerts, warnings, display panels, consent panels and the like intended to
notify the user that the user's location data is being collected, transmitted, maintained,
processed or used, or intended to obtain consent for such use. If consent is withheld or
withdrawn, Applications may not collect, transmit, maintain, process or utilize the user's
location data.
Content and Materials:
3.3.10 Any master recordings and musical compositions embodied in Your Application
must be wholly-owned by You or licensed to You on a fully paid-up basis and in a manner
that will not require the payment of any fees, royalties and/or sums by Apple to You or any
third party. In addition, if Your Application will be distributed outside of the United States, any
master recordings and musical compositions embodied in Your Application (a) must not fall
within the repertoire of any mechanical or performing/communication rights collecting or
licensing organization now or in the future and (b) if licensed, must be exclusively licensed to
You for Your Application by each applicable copyright owner.
3.3.11 If Your Application includes or will include any other content, You must either
own all such content or have permission from the content owner to use it in Your Application.
3.3.12 Applications must not contain any obscene, pornographic, offensive or
defamatory content or materials of any kind (text, graphics, images, photographs, etc.), or
other content or materials that in Apple’s reasonable judgment may be found objectionable by
iPhone or iPod touch users.
3.3.13 Applications must not contain any malware, malicious or harmful code, program,
or other internal component (e.g. computer viruses, trojan horses, “backdoors”) which could
damage, destroy, or adversely affect other software, firmware, hardware, data, systems,
services, or networks.
SDK Agreement Page 6
3.3.14 If Your Application includes any FOSS, You agree to comply with all applicable
FOSS licensing terms. You also agree not to use any FOSS in the development of Your
Application in such a way that would cause the non-FOSS portions of the SDK to be subject
to any FOSS licensing terms or obligations.
Cellular Network:
3.3.15 If an Application requires or will have access to the cellular network, then
additionally such Application:
Must comply with Apple's best practices and other guidelines on how Applications should
access and use the cellular network;
Must not in Apple's reasonable judgment excessively use or unduly burden network
capacity or bandwidth;
May not have Voice over Internet Protocol (VoIP) functionality using the cellular network.
Check out this thread about app store rejections: Reasons for rejecting iPhone application by Apple store
And yes Apple's cut is 30%
You need to be a registered developer. But the information is here.
Related
I need to develop an application that will behave differently depending on the user's country. Let's say, if the user is in France, some functionality would be available. But, if the user were from India, he would be able to acces a different set of functionality.
If it were only language based restrictions, I could switch functionality using NSLocale class methods. But my functionality is really dependent on the user's country because of licensing and legal reasons.
What are the best practices for dealing with this situation?
For each market where you have specific requirements due to market-specific licensing or legal issues, you can create a separate app in iTunes Connect and make it available for download only in the relevant market. And if you need to, this also allows you to provide a market-specific EULA. It's a big maintenance burden, but it would ensure that only users in a given market can access the app.
Note that in XCode you can fairly easily build, deploy and publish multiple versions of your project built from different configurations (XCode calls this "Targets"), so you could still achieve this in a single codebase by simply adding some preprocessor definitions in the relevant target definitions and putting #ifdef in your code where you want differentiated logic.
A 3rd party app has no access whatsoever to any information about the user of the device or access to the iTunes account. There is no way to know the user's true country. At any given time, the device may not even be associated with any one person. An iPod touch, for example, may have no user logged into any iTunes account. The same device can ultimately be logged into one of several different accounts.
All you have access to is the user's current GPS location (if the user allows your app to access that information) or their current locale.
Basically, there is no way to do what you need. Of course you could prompt the user but obviously there is no way to verify this information.
If targetting iOS 4, you can use the Data Protection APIs.
If you have 'Full' protection, does this encrypt the entire sandbox?
Specifically, If I downloaded say a .doc file to disk programatically will this be encrypted? Or is it only encrypted if I use the NSData data protection options?
It's only encrypted if you use data protection. See App States and Multitasking, and Protecting Data Using On-Disk Encryption.
My understanding is that you must use the data protection options. There was a WWDC 2010 talk on exactly this topic. See "Session 209 - Securing Application Data" which goes into detail. These videos are free and highly informative.
Login through developer.apple.com and then you can use the link in the page to get to the videos. FYI, the video contains all the example code you should need.
WWDC 2010 videos
if somebody were to jailbreak your device and bypass your passcode, information protected by the Data Protection API would remain encrypted and therefore inaccessible, since your passcode—the important piece of the decryption key, is not known.
Data Protection is enabled automatically simply by setting a passcode on the device.
The catch, however, is that the Data Protection feature only secures data in applications that have been specifically designed to use the Data Protection APIs.
In terms of built-in applications, that’s only the Mail app, and third-party apps that actually make use of the Data Protection features are surprisingly rare;
GoodReader and Box.net come to mind as good examples, but many other file storage apps such as Dropbox do not provide this support, meaning that your cached data is no more secure than your physical possession of the device.
This means that if you’re concerned about storing confidential data with secure encryption you will need to look to exclusively using third-party apps that support the Data Protection APIs.
It’s also important to keep in mind that any apps that use iCloud storage cannot use Data Protection, as the two are mutually exclusive due to the requirement for background synchronization of iCloud data when the device is locked.
Even GoodReader, for example, notes that documents you choose to store in the “iCloud” section of the app will not be protected by the Data Protection encryption.
Of course even Data Protection is only as secure as the passcode on the device. Using the Apple Configurator you can configure requirements for more complex passcode policies on devices to help improve security in this regard, as well as enabling an automatic erase of the device after a specified number of failed attempts.
Read more at
here
If I recall correctly, starting with iPhone 3GS, hardware encryption is on by default for data on the iPhone, and additional encryption is available if you implement -- though if you are distributing/selling through AppStore, and you're implementing your own custom encryption beyond what Apple provides, the terms of AppStore requires you to get US Dept of Commerce (if my memory is correct) approval because encryption is classified as munition.
A good starting document is http://www.apple.com/iphone/business/it-center/security.html
More info on this is available within (paid) iPhone Registered Developer website which for obvious reason, I couldn't reveal, and you'll have to discover/read yourself.
Hope the information helps, and please mark the response as answered if this helps, thanks.
Do any SO users know anything about these security flaws that have emerged from the German government of all people?
http://www.guardian.co.uk/technology/2010/aug/05/apple-security-weakness-ipad-iphone
Is it possible to understand what sort of vulnerabilities this type of hack could have (e.g. on debit/credit cards?)
This is a buffer overflow vulnerability that affects the iPad/iPhone/iPod Touch. It is triggered by viewing a specially crafted PDF file and gives the attacker complete and total control over the system. In fact the attacker will have more control over the system than the user, or any app developer. The attacker will be able to obtain any and all information stored on the device, this includes credit card number and passwords. The attacker can install a backdoor and access the device any time it is connected to the internet.
Apple has a bad history of security. To metigate this issue you should avoid opening pdf's until you have applied the iOS 4.1 patch. Expect more vulnerabilities like this in the future.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I tend to believe that developing mobile applications in an enterprise environment is best suited by developing intranet web applications. That said I have been asked to think about whether there are specific enterprise applications that could only be accomplished or would be more successful as native applications. I am curious as to what the Stack Overflow community thinks.
Note: As an organization we primarily use BlackBerry devices but are other platform curious.
A few of domains seem better suited to native apps off the top of my head:
Applications with disconnected data sets. Mobile apps cannot always count on having an Internet connection. Native apps handle that case well. This is especially true for data entry tools. If you receive a call in the browser while entering data, the work may be lost if the page reloads after relaunching Safari.
Apps that need the user to upload media like photos, videos, and sound recordings. Currently, there is no way to upload local iPhone media via MobileSafari. Native apps handle this case. Insurance and real estate might be good markets to target with this.
Advanced processing apps. For example, if you wanted an inventory management app that could read barcodes using an iPhone's camera, a native app can process imaging data much faster. Any augmented reality app would run best as a native app.
High memory apps. When other apps run, Safari still chugs along in the background. If those apps need more memory, Safari will release the RAM allocated to a "tab's" page contents. That page then reloads the next time a user opens Safari. If your app needs lots of RAM, then making it a native app gives you higher priority than remaining a web app.
Needs to run in the background as a service. Starting with 4.0, of course, you can build IT asset tracking services, GPS logging, corporate messaging (think Microsoft Office Communicator for iPhone, etc.), regulatory compliance monitoring, order notifications, custom SIP/H.323 endpoint for a VoIP switch, etc.
Large datasets. I believe Safari limits SQLite databases to 50 MiB max. For a native app, the available space will be constrained primarily by the available space on "disk."
Actually, just looking through the API. Any API not available via a webapp would be a good place to start. I'm being coy, here, regarding 4.0 API's that are currently under NDA. :)
That said, SproutCore Touch provides a good web platform that is specific to touch interfaces.
While there may be some specific enterprise applications that are best as a native app I can't think of any concrete examples.
However while I agree with you about intranet web apps are typically better, I think that all depends on who its better for. Obviously intranet web apps are better for development, and better since they can be cross playform, however I think that virtually all apps are better native for the end user. Don't agree? Look at the number of successful iPhone and Android apps that are out on the market that are just native portals for some site's data. Users far prefer the way a native app works over a mobile browser.
Also another thing I would take into consideration is if the app already has an intranet web app in use designed for desktop systems. If there is one, I would go the native app route since the users on the other mobile platforms can still access the desktop version. However if there is no universal portal I would consider doing that vs native.
The ideal would be to do both.
Have something like a secure restful interface that feeds json or xml to a native mobile application. The restful interface would be easier to start with, easier to test, easier to prototype, and easier to change. It would also make life infinitely easier when the data needs to be synchronized, backed up, cloned, or when the phone gets lost/broken/stolen/upgraded.
And then, having a native application built in addition to the restful interface would also allow for the use of the Native UI environment. It could allow the app to work offline. It could use its own notification-system, without going through SMS/push-mail. And if some of the relevant data was indeed mirrored offline, the application would become also more responsive, and much easier to use with other apps (where it comes App-functionality sharing, I'm only speaking for the Android SDKs here, and mostly the future version of the iPhone SDK, not the Blackberry yet). The end result would probably a much cleaner and much more pleasurable application to work with, assuming it could also be done as a Native Application.
I would recommend that the decision regarding whether to create a web application, native client, or both, should be made after understanding the problems you intend to solve and examining the needs of the end users of the application. It would be impossible to suggest that you can answer the technology question without understanding the user problem.
In Chapter 8 of "About Face 2.0: The Essentials of Interaction Design", Alan Cooper talks about software postures. One of these postures is called the "Sovereign Posture." This posture represents an application that is typically used full screen and for long periods of time, and represents the primary application for a given user. Visual Studio and Eclipse are good examples of sovereign applications for developers. If the interface in question is a sovereign application for a user, that strongly favors a native client.
In a specific enterprise example, a service desk application is a sovereign application for technicians, but it is a transient application for users. I would suggest that an ideal factoring of such an application would be a rich native application for both desktop and mobile devices for technicians, and a self service web interface for users. For the technician, the advantages of a native application outweigh the costs of deployment, given that there are generally fewer technicians. Also, the technician may be working on a network problem, and the offline reliable nature of a native client allows the technician to continue using the application even when the network is unavailable.
If the user spends more than a few hours a day interacting with the application, then strongly consider the advantages of a well designed native client. If there are multiple users, consider how each role uses the application, and perhaps you end up with a hybrid model. Your UI strategy should always be based on examining use cases over following gospel from either camp, and should be focused on the user experience, not developer convenience.
The pros of native app development are primarily around getting access to hardware features that aren't accessible through web APIs, obtaining native performance benefits (such as in action gaming), instant access to paying customers through a platform store (such as iTunes), and security situations where you don't trust the browser or how it's handled.
The cons of native app development are that you lock yourself into a potentially proprietary code platform, write a bunch of device-specific code, and you're vendor locked. Code is harder to write, much harder to deploy, and you stand the chance of having the rug pulled out from under you. (Yes I'm looking at Apple, but could happen to any proprietary platform.)
Web apps by contrast are based on technologies that are widely known and easy to deal with - HTML5, CSS3, JavaScript, and excellent libraries such as JQTouch are available to help. Well-designed web apps for the most part will not care if you're on a Blackberry, Android, or iPhone, and will work on many of the older and less capable models as well as the newer ones and devices we haven't even encountered yet, without having to recompile or refactor (or at least without having to do a great deal of recompiling or refactoring...) And there are some hardware features accessible, such as GPS through the geolocation API.
But on the other hand web apps may not perform well with large data sets or high computational requirements. If you're building a commercial app with financial transactions, you very likely will have to roll your own payment system. And you have to trust the browser security as well.
All in all, most apps are going to make the best sense as web apps. However, many web apps can be made to function to be almost indistinguishable from client apps. With some HTML5 offline storage, CSS3 and JS functionality for transitions and behaviors, many business apps can be made to be indistinguishable from native clients.
In iPhone's case we can take it further: Adding a 57x57px icon apple-touch-icon.png to your web app’s root directory will provide iPhones with a nice custom icon when users add an app to their home screens (iPhone will take care of the rounded corners and glossy visual effect) and you can make an iPhone app go full screen when clicked from it’s home screen icon by adding . At this point, the app has it's own icon and runs full screen - the user doesn't know it's web based.
And if you do want to go native but don't want to abandon web standards, most native APIs provide the ability to develop native clients based on HTML/CSS/JS using a simple wrapper, such as the UIWebView in Objective-C. PhoneGap is an excellent cross-platform framework enabling standards-based web development practices to be deployed on iPhone, Android, and Blackberry.
I've been doing mobile app development for a long time (2001?), but the systems we worked with back then were dedicated mobile development environments (Symbian, J2ME, BREW). iPhone SDK is a curious hybrid of Mac OS X and Apple's take on mobile (Cocoa Touch).
But it is missing some stuff that other mobile systems have, IMO. Specifically:
Application background processing
SMS/MMS application routing (send an SMS to my application in the background)
API for accessing phone functions/call history/call interception
I realize that Apple has perfectly valid reasons for releasing the SDK the way they did. I am curious what people on SO think the SDK is missing and how would they go about fixing/adding it, were they an Engineering Product Manager at Apple.
The biggest shortcoming in my opinion is support for separating licensing from distribution.
What I mean by this is that it should be possible to download a trial version of an application and later purchase a license for that application (from an API call inside the application or from the app store). This would make it much easier to try-before-you-buy and get rid of the current duplicates of many applications with 'lite' versions.
I think lack of push notifications for apps is the big thing we're missing right now. With push, you can register your application to perform a task (like getting the most recent data from a web service) even when it's not running, at a time and frequency the OS decides is best. In an ideal world, along with the existing concept of iPhone apps loading quickly and resuming where you last left off, this solves the problem of not running in the background. I know some tasks will be more difficult or maybe impossible with this strategy, but it's still a pretty good compromise between third party applications and the iPhone's limited hardware.
Originally push was scheduled for last September, but it was removed from the beta SDK and not spoken of since then.
API's I'm personally looking for:
Apple80211 as a public API (private, current API is fine if documented)
Access to Volume buttons (semi-accessible via Celestial, private, needs new API)
Access to Calendar (private, API status unknown)
Access to Bluetooth + SPP profile (status unknown)
Access to Camera (directly, API status unknown)
Access to JavaScript runtime (directly, not through UIWebView, API status unknown)
WebKit access that's lower-level than UIWebView (private, current API is fine)
Access to Music Library (private, current API is fine)
Garbage Collection.
CoreData is missing.
You've mentioned some of the big ones - copy & paste (or in fact any way for apps to collaborate) is another huge omission.
It also seems to lack a desktop synch framework (at least if it exists I can't find it).
Language independence and especially lack of scripting is another pet peeve - objective-c is all very well but more languages to choose from would be good.
Inability to dynamically extend apps, via scripts or otherwise, is another big omission. This is partly an SDK/OS issue, partly licensing.
My list ordered by priority:
Mapping abstraction (the MapKit looks awesome), but that would require a new Google Maps TOS
Music library
Camera (photo + video) Access to more
UIViews, Apple designed some pretty nice custom ones for their apps
Better UIWebKit abstraction
The features I see missing that it should have is
Access to SMS
Direct Access to Google Maps App. You should be able have access to this so you could extend your application to use the built in features provided by Google Maps.
Access to the Bluetooth functionality of the phone.
Access to the Calendar. Why not allow access to simply post a calendar event for the user.
Access to Active Sync. It would great if we could directly access this and communicate back to the Exchange Server.
Core Image. They provide Core Animation but Core Image is missing. I hope that this is added to the API soon.
These are some of the features that my clients have access for in the past and are supprised when they are not available.
We definitely miss a Calendar API and SMS access. So many applications could leverage such APIs. The iPhone allows users to have everything in their pocket, but it's almost useless as long as developers cannot leverage this integration in their apps.
A language with proper namespaces.
A limitation that bugs me is lack of access to system features that require root or setuid. For example: opening privileged IP ports.
I'm not sure there is a good solution to this, as long as Apple's policy is to keep the device locked-down.
Allow program to set some kind of local timed event for your application to bring up an alert and launch your app if the user agrees (like any calendar app). You could do that with push notifications but there are many cases I'd hate to have to rely on a whole server infrastructure and network connectivity just to basically do some timed thing.
Some idea of what direction the user is facing. I cannot believe the GPS chip the newer iPhones use are not capable of reporting direction.
I would personally love to see
Access to the CoreTelephony Framework (Currently private). Which allows access to all the phone functions (Especially sending MMS / SMS).
Some sort of ability to run stuff in the background. While push notifications is ok for most things, but it is a bit hard to leverage CoreLocation (i.e. have the app show a notification at a certain location). Of course this would probably need an on/off button or app specific like push is.
animation view which will be reduce developer to make a cool app , of course the core business local still need consider more , but the view layer could more easy to use ....