Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I finish building my app and I don't see any error on xCode 4.2! Do I need to test it on the Instruments before send it to appStore?
You don't NEED to test your app although it would be nice for your users, instruments will let you see the performance of your app and also whether or not you have memory leakages.
Give it a go if you can Instruments.
I strongly recommend you to test your app on a real device before submitting it to the Apple Store because in various situations (depending on the size and complexity of your app) there are some errors or warnings that don't appear on the simulator but do appear on the real device. An example on this is the Media Player (this post is an example).
Another important reason is that the simulator does not support all real device situations. For example you can not receive Text Messages (SMS) or incoming calls on the simulator, and it is important that you test your app for such situations (handle states of appWillResignActive, appDidBecomeActive...).
And as our friends noted above, it would be nice for you to see your app in the way your customers will see it before you sell it to them.
It's not mandatory, but I'd recommend it - particularly if you were an indie developer looking to start making your mark on the Appstore.
Any warnings that Xcode presents are also acceptable - but anything serious that occurs during runtime and through the things Apple will do to it during the submission process will be flagged to you; you'll even get a crash log. (again, as a rule of thumb I'd recommend clearing warnings where possible - and given any time restraints on the project)
Just remember that no matter how much testing Apple will do - their systems can and DO miss things, like specific configs or situations on iDevices that just happen. (just because iDevices are very less fragmented in comparison to say Android, things always occur!)
Hope this helps - good luck!
Also, you might find this useful:
http://www.raywenderlich.com/2696/how-to-debug-memory-leaks-with-xcode-and-instruments-tutorial
Instruments is for performance analysis and is not necessarily a "part" of your app building process. It would be nice for you to do some profiling for your app using this tool so that you, as the developer, give the best UX to the end user.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm thinking about an App I would like to sell at .99$ on Apple App Store. Not so much, but I would like to limit piracy (or at better avoid it).
What are your approaches or best practise in this field?
Freemium (some features free, some others not) model?
Encryption of some client/server comunication?
Some sort phone detection (IMEI, whatever?)
Antipiracy code library (if exists)
I see piracy as a big concern for mobile developers, don't you?
I think this is a debatable issue. After reading and searching about this topic I came to the following analysis:
Preventing app piracy is not possible 100% (remember that even big programs on PC and Mac are pirated like the OS itself, Adobe Suite, big games...).
The people that get a pirated version of your app are NOT your customers anyway:
a. Those who are used to piracy are not interested in paying at all.
b. If the app is not able to be pirated, the pirates people will still not pay for it and will decide to live without it!
Using pirated versions of your app is a way of advertisement: when they will use your app their friends will see it, and if it is a good app these friends will want to get it.
Not all pirate friends are pirates, therefore you will still get customers indirectly from these pirates.
And what is more important, if your app is REALLY nice, in short time even the pirates will buy it. Why?? Simply because you will be releasing updates and bug fixes regularly, while stealing your app will take time and it will not be in the speed of releasing the updates. So the pirated versions will be always delayed in versions; therefore the pirated versions are either lacking some new functionality of your app or still containing annoying bugs that are no more existing in the new versions. So because your app is really nice the pirates will give up and buy it :)
Based on these analysis I decided to accept the fact of piracy and live with it!
For iOS unless you have jail broken your device the only way to get apps is through the AppStore. I think this greatly limits piracy. For Android devices it might be a little higher due to the open nature of the platform.
I think a low price and great functionality is the best bet against piracy. Most people don't mind paying a buck or two for a decent app.
There isn't a whole lot you can do. Honestly piracy in apps usually only increases its popularity and increases sales in the long run. If people really want to get your app without paying they will find a way to do so, and if you manage to "prevent" it it still offers you no more sales. Obscurity in the millions of other apps is the larger problem than the gaining the small amount of sales from people who would have been willing to pay if they were prevented from pirating it. Unless you have an app like angry birds which is widely known and very likely to be downloaded by a lot of people willing to pay it isn't worth the preventative measures in my experience. Good luck though.
-Adad64
Of course piracy is a big issue, but there is not much to "avoid" it. Here is a blog post discussing this topic and a step towards anti-piracy for iOS.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I make an app which is a clone of a well-known game. I had the name of that game as a keyword in the first two versions of my app. Many competing apps also use the keyword.
I just updated my app. Apple said I couldn't have that keyword and took it out.
Meanwhile, a search on the name of the game brings up over 40 apps, most of them third-party apps which are not licensed. Now that the keyword has been removed, my app does not come up in the search, even though it is highly popular.
Is my best bet to:
a) Point out the discrepancy to Apple.
b) Try again in the next update
c) Give up.
d) Something else?
Apple's official policy changed a while back to disallow the use of competitor's products in your keywords. Have any of the other apps that use this keyword been updated recently? It's entirely possible that their use of the keyword dates to before this policy change.
If I were you, I'd go with "a) Point out the discrepancy to Apple" and probably ask them why they took it out to begin with.
If I were me, I would just ditch Apple and move on (Android, maybe even Windows Phone 7).
(a) and (c).
Using unlicensed trademarks as keywords seems to be a violation of the App store guidelines (but IANAL). If you point out those other apps to the review board, it probably won't help you directly, but there is some small chance that sometime if the far future when these other developers try to update their apps, the keyword will be disallowed for them also. But don't count on it.
Your being allowed that keyword originally is part of the luck of the game. Don't assume that a some amount of luck won't be involved with Android and Windows Phone (et.al.) App store revenues as well.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
I want to develop an iPhone callerID application. I have following challenges to develop
How to detect incoming call?
Need to start my app when an incoming call occurs
Please help me out..I am new to iPhone development.
Thanks,
Srikanth
You can't do this. iOS apps cannot launch themselves without direct user interaction, and incoming calls suspend any apps that are already running.
I'm fairly certain this would be impossible in the iOS framework. Incoming calls suspend any active application and take priority over other operations. Further more even if you did manage the overwrite the iOS app lifecycle I think it is highly unlikely that Apple would approve the application because it attempts to replicate the functionality of the Phone app's caller ID. Apple doesn't like it when you try to replace their products (Ask Google Voice). They may have started to loosen up a little on this (See Opera browser and Skype apps) but I think this one would get flagged and rejected.
Short answer: you can't.
Apps are started when a user requests it, so you can't tell an app to start when a call comes in.
And an already running app is suspended when a call comes in. You can't pick up any detail about the call.
No. Simply you cannot do that. There is no public API is available to do that. Your app will be in sandbox environment and your app will be suspended when a call comes in. You cannot access them in anyway.
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 5 years ago.
Improve this question
I have submitted my first iPhone app and am now waiting for approval. My only fear is having it rejected because of some subtle nuance in the HIG, this is from googling around.
How does Apple treat the HIG, as guidelines or as gospel?
It all depends.
If you use the wrong icons for certain functionality. They will reject it.
If it is confusing to the user. They will reject it.
If the standard UI components do not work as expected. They will reject it.
If an operations fails without appropriate feedback. They will reject it
But they will usually tell you one item in the GUI that they rejected it for.
Thus when you fix it and send it back they can tell you about the next one.
They are definitely guidelines, but if you don't have confidence or a good amount of experience with UX, you should treat them as gospel. When developing mobile apps, I kind of feel that providing a good UX should be the highest priority. A lot of developers are pretty bad at UIs, and the HIG provides a very good set of guidelines to follow, at least at the start. You should owe it to yourself to give a HIG a thorough read.
Guidelines. The bottom line is that it has to work, not use any private API or violate the terms of the agreement. If it does what it says it's going to do and doesn't crash right away, you'll probably be fine.
It really depends on how much your devition results in a better user experience.
The HIG is there to help you build an application that users will understand how to use more or less from the start, and make the application easy to use.
If you do some custom things that improve life for the user, Apple will probably let it go. But if you are deviating in ways that make the application harder to use, they will tend to come down on you.
A lot of the possible rejections are pretty reasonably things - for example I was rejected once for a rotated view where the UI elements didn't quite all replace correctly. Once fixed (and it really was a bug on my part) the app was accepted.
The HIG is more a way to change your odds in a lottery. You greatly improve your odds by not doing anything that clearly looks like a violation of the HIG. There are web sites that list things that appear to at least one reviewer to be violations.
But there are many apps with fairly crufty UIs (that don't look HIG compliant to other devs) but somehow got accepted into the App store. On the other hand, one hears about other apps that are rejected for something that looked to the reviewer very different than it looked to you (would you confuse icon X for the completely different icon Y? & etc.) Or mistake the word "or" for "and" in one of the SDK Agreement rules?
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
I set it to iPhone/Network mode, but the device never appears anywhere. Connected and running an app through xcode. Do you know a useful tutorial for this?
This answer provides a step-by-step guide to connecting Shark to a running instance of your application on an iPhone.
As far as tutorials on how to use Shark, there are the following:
"Optimizing Your Application with Shark 4"
"Optimizing with Shark: Big Payoff, Small Effort"
"Optimizing Your Application with System Trace in Shark 4"
"Using Shark and custom DTrace probes to debug Nagios on Mac OS X"
Among the most powerful things you can do with Shark is to do a time profile of your application, then right-click on the low-level symbols (objc_msgSend, etc.) and charge the symbol or library to its caller. This very quickly lets you determine what methods of yours are chewing up the most CPU time.
When dealing with multithreaded applications, I find it useful to do a system trace and then examine the timeline to see when various threads were executing. You may wish to show the advanced controls (Window | Show Advanced Settings) to enable more visualization options. One the Mac, it can be useful to turn on CPU coloring, but that's of little use on the current iPhones.
Personally, I would suggest picking up the WWDC videos from year 2009's conference. If you only take the iPhone track, they are a great deal at $299. There are a couple of sessions that show how to use Shark and Instruments to tune iPhone applications. Additionally, if you pay for the ADC Select membership, you'll have access to several videos on using Shark from previous WWDC conferences. I learned most of what I know about Shark from these videos.