I'm whipping up a short specifications/requirements document for a small prototype iPhone app project. Describing the basic functionality and behavior is not an issue for me. But, since my mobile application and iPhone development knowledge is very weak, I'm not really sure what else should be in such a document regarding best practices and such.
Example: In my programming world (server side Java), when spec'ing a project for outsourcing, I state that the project must pass static bug analysis by FindBugs.
Example: I understand that there are API calls Apple does not want app developers invoking. These can be cause for having an app rejected from the app store. But I'm not sure how to say that we want Apple's guidelines respected. (I don't even know how to test for that.)
What should I include in a two-page requirements and specification document that is specific to iPhone app development?
These are some points you can mention
1. The application should be developed based on Apple's user interface guidelines
2. There should not be any private API call inside the project which makes the application rejected from apple
3. There should not be any memory leak or excess memory allocation issue during the application running state
4. The application should be supported in all iOS after [your option]. (It mainly depends on the features used in the application)
5. The application should be supported in iOS 4
6. The application should work properly on iPhone 4
Hope this helps
A private API wont be mentioned in any header file or in the documentation so one way to test for that would be to manually go through the source files and search for the functions used in the headers and documentation to see that they are there. It's really not feasable if the project grows but for a small app it could work :)
In addition to the things already mentioned here, I'd add a few more:
The app should work fast, no action should give the user the feeling, the device is doing something
Everything that takes a while should be run in background and even better, be cancelable
Make sure you use animation only where it makes sense but not too seldom. A smooth feeling is most important for users.
These things also imply that you try to minimize application startup time.
There are often tricks to work around performance issues. The feeling a users gets from your application is not how fast it is, but how fast if feels. In my opinion this is the single most critical requirement, besides obvious ones like no crashes etc..
What's the problem with using a private API?
Moreover, I would add that it will be tested on iPhone 3G, 3GS, iPod, 4, all with iOS4 and 3.
Related
I know that Swift libraries can be statically linked, but I'd heard that linking in Swift would cause Apple's private API detectors to prevent it from going into the App Store? Is this true?
Found a link on an Apple Forum; hopefully it helps you, I haven't yet submitted anything to the AppStore yet.
But overall, seems like it's possibly more trouble than it's worth. If you get denied, you're possibly then going to spend time rebuilding/reworking.
Seems to be one point brought up, is to ensure you've added all files needed to compile your App, in your submission.
Link below:
https://forums.developer.apple.com/thread/94488
As of Xcode 9 beta 4, Xcode natively supports static libraries with Swift sources. but You have to use dynamic lib
Here is how Apple describes their dynamic framework:
Two important factors that determine the performance of apps are their launch times and their memory footprints. Reducing the size of an app’s executable file and minimizing its use of memory once it’s launched make the app launch faster and use less memory once it’s launched. Using dynamic libraries instead of static libraries reduces the executable file size of an app. They also allow apps to delay loading libraries with special functionality only when they’re needed instead of at launch time. This feature contributes further to reduced launch times and efficient memory use.
Source: https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html
I have a simple iPhone app, mostly table views, map views and other standard stuff. When I change the project settings to make it universal, everything works fine after a few small tweaks. So the iPad version looks just as a big iPhone app.
Definitely, the app will look better if I use some split views, pop-ups and generally rework the UI to look better on the iPad. But I wonder - will Apple review team accept a universal app that is basically just an enlarged version of the iPhone app?
As long as you explain what's changed when you do an update submission (e.g. "now with an iPad-friendly User Interface!"), Apple should accept your update no problem.
What are you afraid of? That Apple would give you a reason for rejection? Just do it, and if you get feedback make the necessary changes. Even if Apple is control freak #1 and a humbling power monster megacorp, I'd be much more worried about it being published and USERS not approving it. :)
iPad users can download and run your iPhone app just the way it is and get the same results either way. From any non-marketing point of view, what would be the advantage to calling it 'Universal' with no changes?
Btw, I've submitted the app without any changes, and it was accepted without any problems.
I was wondering if anyone has any experience with uploading applications.
At the moment we have an application without any leaks, and how hard we even try to create a crash, in both the simulator and the actual device it just wont let us crash it.
Now we're curious if there are any other developers out there that has been in the same situation and sent their applications to the app store and what the actual outcome was. As we're very cautious and dont want to waste our company's resources we'd like to get as much feedback as possible and cover everything before submitting to the app store.
Please feel free to share.
Thanks in advance!
Ensure you don't use any undocumented API's immediate fail.
Follow the Apple criteria and make sure your app fits their restrictions....
Check my post App Store Approval which contains a link to the criteria....
Good work having a thoroughly tested app and I admire your desire to ensure your submission is pain-free. Good luck!
If it does want you want, and you are happy with the amount of testing you've put in it..and it follows Apple's app store guidelines, I'd say its ready for the app store. Quite a large number of apps have huge glaring bugs, so if yours never crashes (doubt this), you are one of the very few.
Also, the process only takes about a week, so I wouldn't say its the end of the world if it somehow gets rejected or you find a bug later.
You can create an ad hoc build and send the application to some iPhone users and ask them for feedback on application. And if app crashes just get the application logs from itunes.
Apart from running a private beta or adding a crash reporter, there isn't much more to do than checking the App Store Review Guidelines and send your first version.
One issue I ran into is that the plural of a word counts as a whole different keyword. Example, looking up snippet won't return applications tagged snippets so be sure to include both of them.
I'm wondering if there are some ways to check if my application is hacked?
I mean, I don't really want to prevent my application from hacking, but I would like to list all iPhone (UUID) that use my hacked application.
Check out mtiks. They do free piracy monitoring, but you'll have to re-release your app to the appstore. If you don't have anything setup currently, you're not going to be able to tell who's using it.
Check to see if encryption was removed from you app bundle or any other changes were made.
If you don't prevent your app from being cracked by any different behavior, such as not working, this makes your detection code much harder to find.
I have a doubt, after finishing my Iphone apps, if i submit that for testing... How they test my application. what are the testing strategies they use, like blackbox testing, unit testing like that.
There are 3 main aspects as far as testing is concerned.
1 The application should absolutely not contain any hidden or private APIs.
2 There should be no crashes in the App.
3 Proper use of Controls.(i.e if you create an iPad app then it should have some controls which are specific to iPad).
Keep these points in mind and i'm sure your app wont be rejected.
None of my app have been rejected.
Thanks
Apparently the two main causes of apps to be rejected are Core Functionality and Crashes. So make sure it does what its says on the tin and it doesnt crash (through memory leaks, etc..)