Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
The guidelines for iOS and the Mac App Store state that demo versions of apps are not allowed.
As far as I can tell, a lite version is (most of the time) just a demo with an IAP for the full version (so as to retain progress)
A "demo" app is traditionally a fully functional app that only runs for a limited time or doesn't let you save anything, or is crippled in some way to make it useless beyond being a demo.
A "lite" app is fully functional in its own right. If a user never upgrades to the full version, the lite app must still do something useful, even if it is fairly limited. One critical thing Apple will look at is no part of the UI must be disabled in a lite app. If a bit of functionality doesn't work in the lite version, then it must not be part of the UI at all.
In a lite app you may have a button or other UI element that lets the user upgrade. If the user reaches some limit imposed by the lite version, you may inform the user that they can upgrade if they wish. But never prompt the user out of the blue to upgrade.
A lite app does not require IAP. You can create a pair of apps (lite/paid) instead if you wish.
If you decide to use a single app with IAP to upgrade, don't call the app "Lite". Don't put "lite" in the icon. Because if you do, your customers will hate you once they upgrade the app and it still says "lite" anywhere.
Provided you're not putting any sort of time limit on your application, or removing functionality from the game - it'll pass as a lite version.
The "removing functionality" limitation is one of those ambiguous statements. You wouldn't get away with removing the "Save" function from a text editor, though you would get away with not having a different model of car in a racing game, or by having it as an IAP.
It's all rather subjective
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
As someone who has never developed an iOS app but hopes to soon and has never had a Mac (to date) the whole XCode and process for developing apps was a little lost on me.
To start: things like which languages are supported in development was one area I wasn't sure of:
I've seen C, C++ and Objective-C referenced as the languages used to write the apps. But I've also seen JavaScript` + HTML + CSS and .NET as options and a host of other compiled languages, with people arguing if you can or can't use them.
Another thing I wondered about was Xcode, does it support all the mentioned languages? Or is an IDE built for a specific language such as Cocoa ? If it is, then how would someone use JavaScript for example to write the app?
I'm sure this is a fairly simple answer to Apple users, but I had some struggle trying to relate from a non-Apple background.
Updated
Thanks for the great answers and insight, hopefully other this post will be helpful to others who don't have an Apple / iOS background
All three language alternatives that you mentioned are available to iOS application developers *.
Objective-C/C++ offers a way of making native apps for iOS, you produce machine code that runs on the devices. You use Xcode to develop in these languages.
You can build apps in JavaScript + HTML + CSS because iOS comes with a browser. Apple offers a mode that gives your apps a completely native look and feel, so they do look like first-class citizens.
You can build your apps in C# as well by using Mono Touch. This is different from .NET, although the language is the same, because your code is compiled into binary ahead of time. Although using Mono Touch eliminates the learning curve associated with the new language, you need to go through a fair bit of learning to adapt your knowledge of .NET to a different platform.
* Except Cocoa, which is not a language, but a collective name for Apple's frameworks for developing under OS X and iOS.
iOS' native language is Objective-C. While it's true you can use C++ to make apps (Cocos for example, is mostly written in C++) it isn't the 'native language'.
As for the other languages you mention, while it's possible to create apps using them they won't be 'native' normally relying upon another IDE/Library, phone gap or adobe air for example. Most of these also support cross platform development.
Where I work we also use HTML5 to create a 'faux native' interface/experience.
If you're new to iOS it's worth while checking out Apple documentation/sample code at:
https://developer.apple.com
There is a wealth of knowledge there that should set you on the right path. It ins't however, something I'd recommend if you don't have any experience with object orientated programming.
Coming from a C++ background myself, I didn't find it too difficult but have been working on iOS for about 3 years (on and off) and am only just starting to really become truly fluent in it's processes and conventions.
Hope this helps, let me know if you want to know anything specific.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I wish to track a set of data my educational app generates based on user challenges. Every nth challenge I want the app to send these metrics to my server so I can observe various things about the app.
Further, and most important, I need to uniquely identify each instance of my app so that I can watch the trends of a single user. I wish to persist this number through the life of the user's interaction with my program in an anonymous kind of way, and persist over multiple removal / installations on the same device.
Bonus points for what your opinion of the standard method of reporting these metrics to a web server are. XML? JSON? Simple NSURL's?
Bonus points for links to relevant Apple Documentation.
DISCLAIMER: (due to past experiences...)
I am relatively new to stack overflow. If this post doesn't conform to the standards of this site, please explain why before voting me off of the island.
You can't tie a device to a user unless you set up a username password combination. Nothing else will work if you expect to handle app removal, installation, or device upgrades.
As for preferred data-type. My preference is JSON. But that's just a preference and you'll get lots of other differing replies. Hence it's a sort of pointless question.
Take a look at this link. It explains what identifiers are constant when and in what situations they are not. He talks about the identifierforvendor and advertisingidentifier that are now the only supported unique identifiers you can access. They took away the UUID tracking as well as the MAC address method. You can still get the device serial number, but that method uses code that will get your app rejected by apple's app store review process.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
Do they use some algorithm such as the ones used in GDIFF program?
Do they ship the intermediate code to the user instead of iOS binary?
Why is it not possible do do a Delta update while updating iOS on Windows?
A delta update is defined as 'an update that only requires the user to download the code that has changed, not the whole program.'
iOS does, in fact, perform delta updates, and contradictory to Ralph's comment, we know exactly how it works.
Applications
For iOS applications, delta updates are used to minimize the download size of new versions, to save internet traffic. Usually, the things that give a program most of its size are the static images and other media. During a simple update such as a bug fix, usually these static images stay the same, and there is no reason to send them over the network again. The only thing that is sent is the actual Mach-O binary containing the code that is buggy, along with whatever files have been changed.
So, delta updates most likely run by checksumming. When you submit an app update, Apple checks the checksum of all files submitted using some algorithm (most likley SHA1 or MD5) to scan for changes. If the executable has changed, but a certain image or other file has not, the image isn't packed with the update, as users have already downloaded it, and don't need to download it again. While this method may not pertain exactly to the definition of a delta update, as it includes executables along with other types of files, it has very similar concepts.
OTA Updates
Apple uses delta updates in over-the-air updates for iOS as well. This is visible on any jailbroken iOS device. Updates are downloaded to /var/MobileSofwareUpdate/softwareupdate.xxxx, where xxxx presumbably is the build/release number. Each software update contains an image of the root filesystem, but not the entire version of iOS is included. Only the files that have changed from the version the user is currently on need to be replaced, and so only those files are included in the update package. The method for finding these changes is likley to be the same as with iOS apps, where checksumming finds changes in the files.
Algorithm
Basically, to answer your question, Apple's algorithm doesn't send the differences between two individual files (similar to what you see in a git commit), but sends the entire updated file. Their 'algorithm' just looks for any change at all between the last version, and doesn't look for the actual change itself. This is proven by the fact that in OTA update packages, the complete files are available, and not just a log of the changes.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
The Apple documentation seems to consistently state that the user-generated documents should either all be stored locally or should all be stored on iCloud. Here is one example from this iOS page (the emphasis on All is theirs):
All documents of an application are stored either in the local sandbox or in an iCloud container directory. A user should not be able to select individual documents for storage in iCloud.
I would like to allow users to manage documents individually: perhaps they want one to be local (to save space from their iCloud allowance), another to be on iCloud so they can manipulate it across devices, and another one to be on DropBox so they can copy it out into a friend's account or back it up manually or even edit it externally. The all-or-nothing approach would actually get in the way of flexibility, especially when I come to introduce DropBox sync. In my case, the individual choice also makes for simpler UI.
So the question is: Can I expect trouble at review time if I stick to my plans to allow users to choose their storage preference (local, iCloud and soon DropBox) per individual document? I haven't found specific guidelines for this. Edit: None of the guidelines even mention iCloud.
It's a should, not a must (just as you should support all orientations on the iPad, but I don't think they'll force you to if the UI would need a complete rework). If you have a sufficiently compelling use-case and a non-clunky UI, I suspect they'll let it through, but I haven't tested this.
If it's not in the review guidelines, then I doubt it's ground for rejections apart from any requirement for "usability" — but honestly, given the average quality of UIs out there, I would not be too worried.
(Indeed, a strict interpretation of that guideline is that you're not supposed to use Dropbox/Google Drive/etc/roll-your-own-cloud-storage, but that's almost certainly not the intent unless they're inviting antitrust lawsuits.)
I did a lot of testing for an app with iCloud. I started with the supposition that it would be transparent to the user whether everything was in iCloud or not, otherwise why would Apple suggest this approach?
Unfortunately, they did not test this fully before rolling it out. I had many problems in iCloud and UIDocument with iOS 4 then 5 (many radar entries of bizarre crashes). In fact, I probably spent half my development time working on this one issue rather than making the app better.
Anyway, the bottom line was that my app was MUCH slower when accessing docs running only on the cloud. Apple does try to cache docs in the Mobile Documents directories. There is minimal info on how to determine status of the caching and therefore try to work around unavailable docs or slowness. The UI ended up extremely jerky in the UITableViews or outright crashed in system libraries.
So, bottom line is my app stores everything locally. If a user makes a change, the app copies it up to iCloud itself and runs background processes to monitor the status of the doc getting up to the cloud. It also manually transfers files changed by another device on iCloud to keep everything in synch, again in background processes.
I've had no complaints at all from Apple reviewers. If I did, I would point them to the many radar entries.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
NB: This question has been extensively edited to make it more relevant, for completeness the original question maintained at the end.
What version(s) of iOS should my App support?
When building a new iOS app what a strategies should one use to determine what versions of the operating system to support? What practical considerations are there in supporting legacy OS version. Are there any reliable statistics to support the business case of dropping legacy support?
Original Question
If I build a new iOS application, should I support iOS versions prior to 5.0, or is that not necessary anymore? Is there any reliable and up to date data on iOS 5.0 adoption rates?
iOS Support Matrix v3.0.1
This version is updated and includes iOS 7.1 and new iPads.
Link: http://www.iossupportmatrix.com
According to this article: http://thenextweb.com/apple/2012/03/06/why-do-developers-prefer-ios-over-android-try-75-adoption-of-ios-5-while-ics-is-stuck-at-1/
the adoption rate of iOS5 has been very fast, at least when compared to Android ICS. You will always have users that are very slow to upgrade, however they seem to be the minority on iOS. If the numbers from the article are correct, you should be fine using iOS 5 for you app.
Look at statistics and judge for yourself if it is worth the effort.
For example:
http://www.14oranges.com/2012/03/ios-version-statistics-march-14th-2012/
http://pxldot.com/post/18754186750/ios-ebb-and-flow
from which I can read that < 11% are still using iOS 4.3
Or just search for e.g. "ios version stats", and try to find a web site that matches the target audience for your app.
This depends a lot on your app. But I would recommend supporting only iOS 5.0 and later because:
The new Xcode creates iOS 5.1 projects by default.
The new Xcode doesn't include iOS 4.3 simulator by default.
Apple has some iOS 5.0 only apps (like iTunes U).
So I guess, Apple is somehow pushing developers to support only the newer versions of the iOS.
Here is a good article that has some recent stats about iOS 5 adoption rates and good arguments on why to support only iOS 5 for new apps.
Here is another good article that discusses the question. Its conclusion is:
I think that both positions (support old, or support only new) are valid.
So it really depends on your special case. But personally, I'll currently support iOS 5.0 or later, unless there are solid reasons for a particular app.
I asked the same question some time ago and did not get any good answer with respect to a reliable up-to-date source of statistic data. In the end it comes down to your target market.
People who do not update their os recently are not likely to buy apps in high volumes. So even if these devices exist, the fraction of potential customers amongst their owners is most likely much smaller. That makes it hard to justify the extra effort in providing iOS 5.0+ functionaltiy and same functionality for smaller iOS.
On the other hand it may be suitable for you just to omit some functions for older iOS. That of course depends on the nature of the 5.0+ function that you want to use. Testing the curent os version and then deciding wether to call a function/method or not ist not that much of an effort. It needs to be tested though.
On the other hand there may be an interesting part of the user community that does consume apps but did not yet afford a brand new device. There is a number of devices around which cannot be migrated to iOS 5.x. And I personally would be interested in a) how many of these divices exist and b) how many of these are still in use.
If it is a new app then adressing older devices may not be justifyable. Unless of course you address some very special interest group and now for sure that the amount of oder devices is of a significant value.
Just some thoughts. Sorry that I did not have the statistics handy that you were looking for.
In my opinion it depends on which features of iOS 5.0 you need...
As example: in an application I need support for forward geocoding, available only in iOS 5.0 so I decided that the number of unsupported devices "cost" less then the effort to find a non apple library for forward geocoding ..