Some of our application is already in AppStore...
But suddenly one thing comes into my mind, that I want to clear before submitting my next application.
The thing is : As a programmer's point of view, should we require to handle if iPhone Device is jailbreaked ? If yes, then how we can tackle with this ?
Thanks in advance....
On a general note, jail-breaking the device is an issue between the user, Apple and potentially the carrier. You are not a side in this relationship, and the user has no contractual obligations to you with regards to their device.
You could choose to attempt detecting jail-broken devices in an attempt to prevent piracy of your app. However:
If the device is jail-broken, there's nothing you can do to reliably verify it's not jail-broken, since none of the OS APIs (including networking) is guaranteed to function as you expect. Your code could be running in a non-jail-broken simulation on top of jail-broken device.
Of course, you could check by attempting to do one of the things you currently know Apple actively prevents apps from doing. However, there's no guarantee that Apple is not going to allow that particular action in future. And, there's the chance that your app might get rejected because you are attempting to do something prohibited by Apple.
There is no official criteria from Apple on what constitutes a jail-broken device and what does not. And even if there was, you are not guaranteed to be notified in a timely manner (or at all) by Apple if they decide to change any such criteria. But even assuming you do get notified somehow, you can't update your app quick enough to avoid falsely detected jail-broken devices, thus potentially denying access to your app to legitimate users.
If you would like to cut off a large group of users, then sure, go ahead and require it.
Unless your application specifically requires it, there should be no reason to force users to have a jailbroken iPhone or a non-jailbroken iPhone.
If you program is legitimate (no private API calls etc), then you should not concern yourself with JB. You don't need to handle anything differently if the users phone has been JB'd. If it has, and your software doesn't run (say memory issues because they are using backgrounder to run 2 other things) then that's their problem not yours. Make your code well behaved, not leak memory, dump cache's etc with memory warnings, and you should be fine.
As you asked for the "programmer's point of view", I'd say: make sure your app runs on as many devices as possible.
Meaning: as long as you app is safe to run on an iPhone whether it's JB or not, I wouldn't care.
One thing I have found, at least early on (not seen it for a while) is that most reports I got of strange behaviour with my app (vConqr) turned out to be from people with jailbroken phones.
That's not to say I think that's good reason to block them. But if you do any sort of custom crash reporting, or other diagnostics it could be useful to log the fact to save time on troubleshooting.
Do a search on the Internet. You'll find several articles that shows some ways you can detect a pirated app. I make no claim on their effectiveness, but I do use some of these in my own apps. These techniques do not try to detect if a phone is jailbroken; they focus on detecting if your app has been tampered with.
Related
I need to create and App that will run in the background and will monitor the user's behavior in term of applications installed, opened and deleted.
i.e Application will save the information in the database that at what time user has installed/opened/deleted an application in iphone.
I wonder if its possible and Apple will allow this??
I tried to google on it but did not get anything, i know if its possible then it would be possible by multiasking only??
Can any one please help me on the same.
Brn
Not possible. Your app can only run when the user chooses to (except for a limited sub-set of tasks like VoIP, etc).
Your app can know nothing about other apps.
iOS apps are sandboxed. I wouldn't say impossible but certainly not allowed. You'd have to find a security hole to give you root access first. Oh, and notify us when you do ;).
Edit:
Maybe it wasn't clear in my post but I was at least half joking. Not sure why you want to do what you want to do. I can imagine the following scenarios:
1) Your company wants to monitor everything their users do on their phones. In that case I would either
a) lock them down and only allow app installation through a company portal (enterprise distribution is possible in iOS) OR
b) forget about iOS alltogether. Blackberry would probably be closer to what you want, although I don't really have experience with that platform. Also, its future is not sure.
2) You're trying to do something illegitimate. Because of iOS's locked down nature it won't be easy. See how few successful attacks there have been in the last years - and that's for a highly successful platform where an attack could be high paying both in terms of money and reputation.
One of my apps is in the appstore and I got a call from one of our clients saying a specific feature in the application is consitently causing the app to crash. However, I don't see any logs in iTunes Connect rightnow. Is there a delay between the app crashing and the log being submitted? If so, how long does it usually take?
Thanks,
Teja.
You'd be better asking them to send you crash reports directly. If they sync their handset using iTunes there will be a copy on their PC/Mac.
Unfortunately it seems that people are syncing their phones less and less often. (Which means they never make it into iTC.) Also, not all of them make it into iTC. Apple aggregate them but there also appears to be some level of filtering. What they do is not documented.
This blog explains what I ended up doing with my apps.
You should use a service like Crittercism - They give you real-time crash reports. You could also use something open-source like PLCrashReporter if you want to implement the server yourself.
The delay really depends on how long it takes before the user syncs their device with iTunes. I believe after that it's pretty quick.
Also it's worth noting that iTunes Connect needs a few crash reports before it displays them.
For the sake of coding itself, I know that I don't need to buy iPhone as there's pretty good emulator.
However, as I will develop iPhone apps for clients (will not have direct contacts to clients) via freelancers sites, do you think that I might get rejected (not chosen) by the contractor because I don't have iPhone at home?
Do contractors accept this way of working:
I develop the app, test it in the emulator and send it to them
They test it in iPhone and send me the list of the bugs
I fix the bugs and send them the app back
They find new bugs and...
Yes, or at least an iPod Touch.
To clarify:
Yes. You really need one. Debugging the kind of errors that cause it not to open on the device at all, for example, can be mind-numbingly tedious if you don't have the device handy.
For most purposes, of course, an iPod Touch should do just fine, but the crux of the matter is that the testers can only test what they see; only the developer can actually test crucial stuff, most of the time.
So to repeat. Yes, you'll need a device. A thousand times yes.
Your client may have something of an issue paying money for software that was never tested on actual hardware. No matter how good an emulator is, you should always try the software on the real machine your program will be running on. The emulator will simulate the way the API responds etc, but you could be blindsided by things such as interference from other running applications, subtle timing bugs, interaction between different versions of the firmware or hardware, etc.
In short, I don't think there is a legal reason you have to test on a real iPhone, but from a Q/C point of view, I think there is no question you need the real hardware to run it on.
Paying customers generally dislike being treated as a beta tester.
I don't think that you won't get the clients - but I do think its a terrible idea not to have a device to test on.
There are many things that won't work properly in the simulator. For instance you can't simulate a camera function, you can't simulate GPS (properly - it always sets you at the apple HQ), you can't simulate sound recording, or test with a real contact address book or a real set up. You can't test whether there is an internet connection or if there are any iphone specific bugs.
On the other side of the coin there are loads of things that will work in the iphone simulator that won't work on the device itself. For instance NSXML and such won't work on an iphone, but WILL work in the simulator.
If you can get hold of one of the new ipod touches they do pretty much most things you will need, and you don't have to get into a data plan or anything. I would suggest AT LEAST getting one of those. You can't make apps if you can't test them properly.
Other things:
In app purchases - #Stephen Darlington
Whenever working for clients, the clients do not pay you for having an iphone or not... or being able to test it on a actual iPhone. The clients pay you for the product you deliver. They expect it to work on the device.
My recommendation is to get yourself an iPhone 3, 3gs and 4 if you want the best results. But, if money is a object here... try developing minor projects which are reliable in the simulator. AND ask friends/family which do have iPhones to test it for you on their device. Its better to ask mates to do this, then ask the client, this way you have a better comunication with your client, your client has more faith in you and... well lets face it, it is the developers responsibility to deliver quality code. Right?
There are some tests you cannot perform in the emulator.
And I am not sure contractors will like this ping-pong test approach (somebody will get tired after couple passes).
You can get an old second-gen iPod touch at a very good price since there are many people who would like to get rid of it. And Apple advices to test apps on older hardware to achieve the best performance. So you'd better get something 'hard' to play with.
Another aspect is performance. The simulator (running on a powerful Mac) will be much faster than a device. This was a huge difference with the original first iPhone.
As an alternative to the iPod: look for a cheap original iPhone on eBay or so. But remember that this will not run iOS4.
is it possible and how to implement forbiden exit from application on iphone/ipad?
we have an application that must permanently work on ipad device. user should not have any way to exit from application. could you advise how to implement this functionality?
By jailbreaking it and installing custom software that enables you to do that.
Or putting a lot of tape over all the buttons.
Anyways, you can't do this with a standard app on a standard device. Just think about it - would be a pretty annoying thing for apps to do, wouldn't it?
Apple's own human interface design guidelines would forbid this. Your app can't encroach on the abilities of the OS that transcend your own application's responsibilities. The whole point is to have a consistent experience for the device and if you're modifying something as fundamental as switching apps, you're violating that principle.
If you can't exit the app, you're essentially turning your device into a single purpose unit. How do you expect to get back to the app list if you disable fast app switching and the home button?
Whatever solution you find would not be approved by the app store.
You should look at whether the current multitasking features can help chip away at your reasoning for needing the app to always run in the foreground.
If you are talking about an enterprise app locally distributed, you might be able to do this, though probably not.
The best idea would be to physically break or block the hardware button.
Or issue alerts to the device every 10 seconds making the thing effectively unusable when outside the application (you can ignore incoming notifications for you in-app).
Why do you have this requirement?
There is no way to implement this functionality. You cannot do it.
You can't do it, But if you jailbreak and configure the "Home-Button" settings you can :)
Btw, If you do it, the only way to quit will be a shutdown... And to shut down every time would be kinda annoying...
Is it possible to assign different identifiers to copies of an app downloaded from the app store that is hard coded into the application? Or is their anyway of permanently storing an identifier in the application bundle such that when it is copied, the key remains within the bundle?
EDIT: Ok, how about iTunes reciepts, can they be used to verify when it was downloaded as the user has to register their app with the server within say 5 hours of them downloading it.
thanks in advance
I'm assuming your goal here is to disable part of the functionality of your app by having a master list of bogus serial numbers somewhere. Unfortunately there is no per-copy serial number available, and if there were it would be the first thing the bad guys would change before posting your app for download.
Instead you'll need to detect whether your app bundle has been tampered with from within the app. See this question:
Reducing piracy of iPhone applications
You'll then need to decide how subtly or obviously you want to limit functionality. Probably the best solution would be to do something innocuous but slightly annoying that generates a specific kind of support request, at which point you can gently prod the deadbeat into considering buying a legit copy.
An approach with more false positives but potentially fewer false negatives would be to check if the app is running on a jailbroken device. The downside there is that jailbreakers may well have legitimately purchased your app, so you're alienating honest customers for little to no extra benefit.
For the app I'm working on, which has a big social/viral aspect (I hope), I've decided that potential deadbeats probably have enough honest friends to pay for the server cycles that they're stealing, and it's just not worth worrying about.
No, there's no way to do either of these. The closest you could come would be to store device IDs on a central server.