Do I have to support jailbroken iPhones? - iphone

We're days away from submitting our first app to the appstore and
last night I was horrified to hear that it does not work on
jailbroken devices. I got a few seconds with the device and saw the OS version, and free memory available (36MB, I guess that's low).
Should I care?
Presumably jailbreak users can buy the app and write scathing reviews.
If so and jailbroken iPhones are common, then the iPhoneJB becomes a de facto shadow-platform that I'm obliged to support.
EDIT
I got some ball park figures, sounds like I should care about the new de facto shadow platform. So either I can try reducing memory requirements and cross my fingers, or get out the credit card and go get me another iPhone to jailbreak.

With around 2.3 million jailbroken iPhones, it is a significant portion of the market. I have a jailbroken iPhone, but most of my apps are from the App Store. I vote yes.

This is a similar issue to what many web developers run into: should they support Internet Explorer 6? While as of this writing 14.9% of the market still uses IE6, many web developers choose not to support it because it is difficult and takes too much time. My own experience was that supporting IE6 caused 50% of my work; that's obviously not a good trade-off.
As Jergason mentioned, there are 2.3 million jailbroken iPhones. Obviously that's a large market. But compare that with the 30 million iPhones total sold as of March 2009. You could probably find better numbers to compare, but assuming those numbers are roughly accurate, less than 10% of the market is jailbroken. Look at how much work, money, etc. it's going to take to support jailbroken phones. I don't know how much work it would take, but when it comes to money, my guess is that simply the cost of getting a jailbroken iPhone to test on will be more than 10% of your revenue (iPhone dev tends to be a small-scale operation, but I don't know the nature of your product so I could be way off-base here).
So my vote is neither yes nor no: do the research and get more detailed stats than I've provided here. When you have your information, don't spend a larger percentage of your revenue supporting a segment of the market than that segment is as a percentage of the whole.

Of course you don't have to support anyone you don't want to! Ultimately, as others have noted, it's a business decision.
In my experience, you'll spend a disproportionate amount of time supporting users with jailbroken handsets. I spent more than twenty hours tracking down one problem that only affected jailbroken phones and even then only found the solution entirely by accident.
Having said that, some of my most enthusiastic (or at least vocal!) users have jailbroken handsets.
At the time of writing, about 25% of users of my free version have a jailbroken handset and 10% for the paid version.
In the end I try to support all users but I do put a higher priority on users with vanilla handsets. I'd draw the line at users of cracked versions, but I have no reason to suspect that's the case.
Incidenally, technically you'd be in breach of your iPhone Developer Program agreement if you used a jailbroken handset. And 36Mb sounds like a lot of available memory for anything other than a 3GS.

The accepted answer to this question seems fine, but I thought I'd add one more (technical) issue to consider.
If you don't at least test your app on jailbroken devices, you may not be aware of some security vulnerabilities. If your app contains any kind of sensitive information, you might want to make sure it can't be easily accessed on a jailbroken device. This might include protecting users' data, or protecting the corporate data on the back end.
Jailbroken phones allow a user to ssh into the phone, and browse any file on the filesystem. The sandbox is nullified (App Store apps will still be limited to their own sandboxes, but non App Store apps will be able to read and write the sandboxes of other apps, including App Store apps).
NSUserDefaults used to store sensitive information, for example, are easily exploited on a jailbroken device.
Even the keychain can be subverted on jailbroken phones.
It would be nice if you didn't have to worry about this, but at least through iOS 6, you really do need to worry about it. So far, Apple has not been able to (or maybe doesn't want to) completely prevent jailbreaking, so it's a real-world vulnerability. Ignoring it is probably not doing your clients or users any favors.

Do your market research. Do you expect to sell to alot of users with jail broken iPhones? Then you need to decide how important that revenue is to you...

Related

iPhone app distribution in a club

I am a member of a gliding club with 150 members, and we want to have our own iPhone app. Requiring a member login, the app would be usable only by members of the club, and it would be used by an estimated 20-30 people.
Is it even possible to disribute such an app to non-jailbroken iPhones? According to my research:
It wouldn't be accepted on the App Store due to "limited audience".
Even if we were able and willing to pay $300 for the enterprise distribution model, Apple would likely not accept us as a company.
Ad hoc distribution would be fine for us except for the expiration time associated with apps distributed in the manner.
Are we at a dead end?
Thanks.
Edit: In case anyone is wondering why I didn't just ask Apple directly: I did, and their answer was, "We are unable to advise you with respect to the Apple Developer Program that best fits your needs."
I'm not 100% on your question.
But depending on your requirement, pretty much everything you need can be achieved as a web app, with the correct coding behind it i.e. CACHE MANIFEST you could make the app function similar to the a native app, available offline and can be saved to any iOS device through the browser.
Give me a shout if you need more information.
Hope it helps
Gary
You could always try to make the app a little more "global"? Perhaps offer some free stuff for Joe Bloggs to use, but tucked away you have your real motive... that way you can get it released legitimately.
I've seen some real disasters in the app store that shouldn't have made it, and I'm sure Apples screening isn't as intense as we might think. (example: that flash light application, when pressing a sequence of buttons it would enable free tethering).
Best of luck!
Yup. You seem to have all the options laid out pretty clearly, and there's no other way to do it. Except developing for android, and just distributing the application freely and without arbitrary restrictions.
Sorry.
Ad-hoc distribution would give you about 90 days expiration time, i think, whereas enterprise would give you a year. Though gaining enterprise status in the eyes of apple is easier said than done.
Even if we were able and willing to pay $300 for the enterprise distribution model, Apple would likely not accept us as a company.
You don't have to be a company to apply for the enterprise account, you just need to be an organisation with a DUNS number.

Alternative to iPhone device identification by UDID

I am on an anti-piracy project. I am trying to re-identify devices based on their UDID. But I am wondering if jailbroken devices are hiding the real UDID and instead using a random generated one.
Is there an other way to identify a device? Perhaps some kind of cookie? Or an other Id/Hardwarehash?
Or can I get the UDID on a reliable way?
Thx for all answers!
Don't waste your time.
Focus on making the app convince your users to spend money on it and don't worry about piracy. There are lots and many apis, tricks and methods to foil piracy and all of them are overcome in a short time.
The idea of a cracker is to show they are smarter than you. So only way to "fight" them is to take their audience away. And that you do by making a great product that users are willing to pay for.
Can't really be done. There is a jailbroken app called UDID faker (also a few others), which will generate a random UDID. Also, because jailbreakers have access to terminal, every feature of the hardware can be altered.
If a cracker knows what they are doing, which they ALL do, then your service will be blown wide open within a couple of days, if not hours.
If Apple can't detect and prevent this, with an army of extremely talented programmers, why do you think you will fare better?
If you could solve the piracy issue, you wouldn't be making an app, you'd be contracted by Microsoft.

Submitting iPhone app to app store without testing on a device

I've tested my app thoroughly on the simulator, but I don't have an iphone/ipad/ipod touch on which to test the app. Are there likely to be bugs that dont expose themselves until I test it on the device?
if i had a macbook, id take my code along with me and meet up with a friend or a stranger to test the app, but im working with a mac mini :(
Thanks for the input.
The one major concern is performance. Devices, especially older ones, have orders of magnitude worse performance than Mac mini, both in terms of CPU and memory. It is possible that your app is crazy slow on a device, yet runs fine in simulator.
Other areas to think about:
network connectivity, performance in poor/no network conditions (good way to test in simulator: yank out ethernet/turn off airport... but some reachability code works differently in device and simulator I think, and you cannot simulate mobile-only [no wifi] situation)
As Rengers said, you should get your friends' device IDs and then create a provisioning profile so they can run the test version of your app which you can e.g just zip up and email to them.
You will really want to pick up a device, an iPod Touch isn't that expensive, and you can even get iPhone 3GSs for less than $100 now at some retailers (contract required). The reason for this is that there have been many cases of the simulator doing one thing while a device does another, in addition to the resource differences (both in terms of available cpu time and memory)
Yes, there are bugs that will only show on the device. It depends on the complexity of your app. For a fairly simple application, chances a bug will show up on the device only will be a little lower.
However, I strongly recommend to test on the device. Bugs aside, you can't get a good measure of performance on the simulator. A real devices has much tighter ram and cpu constraints.
If you have a developers account, afaik you can distribute apps to testers. Perhaps someone else with an 'iDevice' is willing to test for you?

Which mobile programming environment do you recommend for a startup to target? [closed]

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.
There's a lot of mobile platforms out there at the moment; iPhone, Android, WebOS, Symbian. If creating a startup for mobile development (i.e. as a commercial endeavour, not a hobby), which mobile platform is worth focusing on?
First, ignore technology to start and instead look at the business model for each platform. Ask if the platform itself has a reliable means of producing revenue long term. If so, then ask if the platform presents a business model that allows a developer to make money. If your not sure about such stuff ask someone with business experience.Beyond an initial flurry of interest, nifty tech can't sustain a platform if the economic underpinnings are not there. Even if a platform prospers, it doesn't mean that small developers will.
As near as I can tell, Android isn't actually a platform but more like a loose standard. Each phone vendor can customize it to a high degree so there doesn't seem to be a means by which you can write a single app and know it will run on all Android phones. That will cause major market fragmentation so even if Android takes off big time that doesn't mean that every developer, especially small developers, will be able to sell to the entire installed base.
Long term, open platforms (like contemporary PCs) present major problems for small developers. There is no intellectual property protection so developers who don't have large institutional customers they can sue can't prevent piracy. Security will become a major issues as black hats target people's phones. There will be a huge number of crappy or actually fraudulent apps cranked out that make end users leery of buying software from a vendor they don't recognize. This means small developers will have a hard time breaking into the market.
One of my professors in college told me something that has proven true in my 20+ years in the computer industry: The major strength of every design is also its critical weakness and vice versa. The very things that make open platforms attractive to developers and customers are also the same things that will cause them major problems. The very things that turn developers off about closed platforms are the things that provide the greatest benefit to developers long term. Having a closed platform's vendor vet every app slows down acceptance and limits choice but improves overall quality, security and consumer trust. And so on...
Career wise, there is a difference in paths between running your own business and learning an API so that others will hire you. In the former, you should develop for the platform that has the best business model and the one you would most like to use as a consumer. For the latter, you should develop for the platform with the most buzz. Even if it flops, no one will find it odd that experience is on your resume. Just rough rules of thumb.
I've written and launched two mobile apps on the iphone over the last year and both have had success in economic terms. One app is free and tied to a web service and it has a significant impact on the popularity and number of users for the web service. The second app is a paid app - and I can tell you that it is producing some actual revenue, enough that if I was a solo developer it'd be paying my bills.
That said I think that if you're launching a company for mobile products you don't want to put all your eggs in one basket. So either support multiple platforms or aim to have multiple products on your main platform.
I think there is big potential in Android but at the moment it is totally unproven as a platform where you can actually make money (please point out some info on this if you have any I am really curious about the economic potential of Android).
Blackberry is also interesting since pretty much everyone I know who's under 25 has one, but it is a platform where selling apps doesn't seem to have caught on that well. I've discussed it with some heavy blackberry users and apps are not something they really care that much about. So you'd want to try to find out some numbers regarding Blackberry app sales.
In the end it depends on your target market/product.
Are you building an enterprise targeted mobile app? - Build for Blackberry first and perhaps iPhone next.
Do you want to launch one consumer focused mobile app with a large feature set and perhaps some web service integration? - target a few platforms and make it available to as many users as possible.
Are you trying to build a series of small purpose built apps? - Definitely start with iPhone and get some revenue first.
My 2 cents.
Not Iphone.
Because of Apple and this strange policy of application approuval. You could not afford to close your entreprise only because apple has decided that your application is "not ok"
Edit : For sure, the AppStore has a huge potential client base. But it's also the only "mobile market place" from where you can be removed.
If you are having a hard time deciding, why not just develop for all of them at the same time!
PhoneGap is a utility that lets you build apps that run on several different platforms. It's great, and the guys at Nitobi are very willing to help you out.
I suspect at the moment you would get the largest pool of potential customers if you developed for the IPhone. Apple do have some issues with their control freakery but, hey, people use their AppStore.
Personally I am going to develop for Android because I absolutely love the design of their OS for mobile systems. Just brilliant. I also suspect that Android will increase in market share rapidly over the next few years. It's also Java instead of objective C so I would think easier to port to other environments as required. I'm doing development for fun though so if I make no money then who cares. If you actually need to make the development pay for itself then I guess IPhone is probably the way to go while keeping a close eye on Android.
The thing about the AppStore for the IPhone to keep in mind is that, not only do people use it, they also PAY for things from it. Android still doesn't let you sell to any country so even if they were to technically have more users - those users might not be able to pay for your stuff even if they wanted to. This is being worked on by google and will change but it does limit the amount of money your app could currently make.
It depends on your target audience. Business users will most likely use BlackBerrys or Windows Mobile (at least in my experience). Consumers (at least those willing to pay for software) will more likely use IPhones.
It depends on the application somewhat, but if you are serious about a startup it makes the most sense to start with the iPhone. The frameworks allow for the most "wow" factor with products, and there is simply a huge lead in number of units, and number of users used to running many different applications.
You may also want to consider other platforms (my vote for second to go after would be Android, and then Palm in third although that depends heavily on what your application is).
But something to consider is, you may want to start by doing one platform really well and if your application idea is well received, branch out. It's a lot of effort to develop for multiple platforms and each platform has various unique features you want to spend time taking full advantage of. I would also advise against using any of the cross-platform frameworks for the same reason, because when you target all you cannot really target one.
Depending on what you want to do, I think you should look at web toolkits. Web apps, a.k.a. Widgets run natively on Symbian, and through Opera on many other platforms. It should be simple to port to Palm WebOS if that catches on.
You can't do everything in a Widget, but you'd be surprised what is possible.
Based on my limited experience with seeing what devices are used on subways, trains, in airports, etc - I'd suggest either Blackberry or iPhone.
But more importantly, pick a platform you like and are excited about.
If you are not enthusiastic about the platform and you are doing it solely for the money then it will show. you might as well just make hamburgers or sell lotto and cigarettes.
Take this with a pinch of salt but this pie chart seems to suggest that Symbian is the most widely used:
http://en.wikipedia.org/wiki/Smartphone
Or Java ?
Java is used on Blackberry's and will run on Symbian.
I wouldn't have said this 6 months ago. But I'd go with Android.
It'll be significantly more work porting in the long run. As more and more screens sizes and device profiles are coming out, but I think it's got the weakest developer market with the highest long-term potential earning power. The iPhone market is flooded, so, even if you get your app published to their catalogue, it's still almost impossible to get any kind of exposure.
Android, on the other hand, has huge growth potential and a pretty poorly followed market-place.
Verizon's massive push on the 'Droid' should open that particular device to a huge marketplace. It remains to be seen, however, if and how they'll allow 3rd parties to publish apps to their catalog.
Depending on your timeline, you might also consider Flash as a cross-platform option. Here's a list of heavy-hitter companies working to make mobile Flash happen in the near future (includes Google, RIM, Nokia, Sony Ericcson, Palm, Motorola, Samsung, etc.):
http://www.openscreenproject.org/partners/current_partners.html
...a video of some of their CEOs...
http://www.openscreenproject.org/about/
...and how to apply for some of the $10MM that Adobe's seeding into the market:
http://www.openscreenproject.org/developers/get_started.html
In summary, I'd suggest going for a cross-platform approach.
Symbian has by far the biggest number of users and has the largest choice for programming languages.
Symbian and Maemo will be running Qt in the near future, as well as supporting open python, open C, java etc etc etc.... (they also both have the Qt libraries available now)
I wouldn't put too many eggs in the iPhone basket. Your application would have to be monumentally good to be found and paid for by a significant number of people in the 100,000 items in their app store.
Android, don't really know anything about it. It seems like it could be a popular platform, its at least a real multi-tasking environment (unlike iPhone from app dev point of view).
Palm Web OS is insignificant at this time.
Perhaps the best solution in fact is to make your application web-based then you can just develop small apps which hook in to the web service?
Mono sounds interesting to me
Mono on Android - androidMono
Mono on Iphone
Like phonegap there is appcelerator titanium

Is there a risk that Apple will not accept me as an applied iPhone Developer (with paid membership)?

What does it mean that I have to "apply"? Can day say: "No, we don't like your nose. Do something else!"? Did they do that in the past?
I've been investing now two full months worth about 20.000 USD on learning for iPhone programming, and I didn't apply yet...
I've never heard of them rejecting an application for developer license. But I've heard plenty of stories of them rejecting code. That's the much larger risk with Apple's stranglehold on the iPhone marketplace.
There is no reason for them not to accept you as a iPhone developer. There is no situation that I know of where they have denied the application provisioning for testing out on the iPhone. They can and will deny your app submission to the app store in some cases. Usually those cases include:
Using copyrighted assets which you do not have a license for
Competing with one of their apps (mail client was the only one I know of)
No value added (yet another "flashlight" app - pretty rare)
Opening the iPhone to scripting attack through download.
Does not conform to their UI guides
The last of these is the trickiest. A friend of mine had his app rejected because he used a UI widget in an unexpected way. This is pretty subjective IMO but they did tell him exactly why they denied it and accepted it when he fixed the issue.
Also about the 20,000, I can't agree here. In addition to learning and bettering yourself as a programmer, you are assuming that you would be paid for every off hour you spend learning - not very realistic.
Apple has a right to not accept your app at their wish, so you have to take a risk.
Yes they could. That's the risk behind developing for any tightly locked down environment.
Of course in practice they are unlikely to reject you for no reason.
And you're already taking a gigantic risk by investing $20k into iPhone development. I can't help wondering if this is a saturated market, although there have been a few well publicised success stories, everybody and his dog are now working on a bejeweled clone, and lets face it, even people who buy iphones are going to be looking a reduction in spending on pointless trivia soon with the market the way it is