I am developing an iPhone game and want to sell it in different regions, making it available in a number of languages.
Should the app be repackaged in each different version for each language, (e.g. Japanese, English, Chinese etc), or would one game package all the art and language and then detect where it is and display accordingly?
Does Apple allow mutliple versions of one game to be submitted, each game with a different language?
By all means go for a single app. And if done correctly - which is very easy - the system will chose the correct language automatically. So don't use a language setting, either.
Having many different versions can easily get a pain, both to support and for the customer, who will simply be frustrated because he easily buys the wrong version.
If I were Apple (which I'm not) I'd say this is a typical case of spamming the AppStore and would ban you from there...
So do the reasonable thing -> one app for all.
As Eiko said, go for one app, although I disagree that Apple would ban you.
Look at the Apple documentation for "Internationalization" for help on how to do so.
Related
I'm close to publishing an iPhone game on the AppStore and I'm wondering what would be the best way to publish a multilingual game...
Should I use the iPhone language settings to load the language accordingly?
Publish multiple versions of the same game but in different languages?
Put a setting on the game to change languages (or would users prefer not to use this one...) ?
Any ideas, recommendations, or best practices would be greatly appreciated.
One app. Period.
Always use the user's current locale, and make a reasonable assumption for default in case you lack localizations users may be using. I've seen most commonly English be used as the default. Myself, I wouldn't even supply an override; the user has the device in their preferred localization already.
I would definitely include all languages in a single app. You could set the default language to the language that the user has enabled on his phone and add an additional option in your app's settings.
Is it possible to build assistive applications for the iPhone that work in the same manner that VoiceOver does? (Using the UIAccessibility API) - To clarify, We would like to build a screen reader in the same vein as VoiceOver. Or, is VoiceOver the only assistive technology that is allowed to work on an iOS device?
Yes, you could build your own screen reader technology into your own app.
You would have include your own speech synthesis library, such as CMU FLite, which may not sound as good as VoiceOver, and subclass or add categories to all of your app's UI and text objects that you wanted to support your private assistive behavior.
There are a small number of talking apps in the iOS App store that do some limited custom voice assistance within some of the app's views, without VoiceOver having to be on. (Advertisement: my Talking Tuner is one example.)
Your assistive tech would only work within your own app, and would not be able to interact with the physical button or any other apps as Siri and VoiceOver can.
VoiceOver is currently the only assistive technology app on iOS, and I suspect that Apple will keep it that way. There's a bunch of benefits to having the screenreader being part and parcel of the whole package rather than allowing 3rd party apps, including:
A screenreader, by definition, needs to be able to access the UI and contents of other apps. There's a whole bunch of security and privacy issues here. While there are some ways to mitigate this - eg. Android requires assistive technologies to be specifically given permission in a control panel - why even go there if it's not needed?
Some of the things that VoiceOver does - like intercepting touch - likely need special system support; and again that's not something that you generally want to allow any app to do. There's a sense in which a screenreader is a special case of app, and it's far easier to manage these cases where a screenreader needs special support from the OS if its all in-house than if that support needs to be extended to 3rd parties via some API, and that API needs to be somehow secured against misuse (see point above), and the API has to be documented and supported in future OS releases.
Having one screenreader means there's just one app to test with for accessibility. This hugely simplifies life for the developer. On iOS, test with VoiceOver, and you're done. By contrast, on Windows, you have to test against perhaps JAWS, NVDA, and maybe WindowsEyes too. And some of these apps do things that others don't, so your app may need to workaround one or the other.
Having the screenreader being part of the package also means that it works with new features right from OS release. Apple can guarantee that new iOS features are accessible from day 1. To do this with 3rd party accessibility software, they'd have to let 3rd parties in on new OS features, which is unlikely for a company as secretive as Apple.
Unfortunately, VoiceOver is currently the only assistive technology allowed. If you need to work with VoiceOver, it is pretty easy; all you have to do is add this line of code for each items you want the user to identify:
[myView setIsAccessibilityElement:YES];
[myView setAccessibilityTraits:UIAccessibilityTraitImage];
[myView setAccessibilityLabel:NSLocalizedString(#"Image of dog", nil)];
I have developed an app for the Android and it's working well, finally, and thanks to all the help from StackOverflow!!
Now I am being asked to make it work on the iPhone. I looked at iPhone a while ago but not recently.
What does everyone think? Should I take the time to learn Objective C and iPhone and port the app or forget it?
Are there any books that cross-reference functions so that you can look up how to do something in iPhone that you already have on Android?
From my experience in school, if you have already been able to create a working smartphone app in at least one mobile OS such as android, it wont take long before you can understand objective C and cocoa framework stuff. The only problem with that is you may probably need an apple developer license to use XCode.
So, I would say go for it since you also get paid, and also here is a link to iphone development guide for android developers : http://integratingstuff.com/2011/02/27/starting-iphone-development-as-an-android-developer/
Probably, it's better to get a partner who develop to iOS than doing it yourself.
Focus on a platform and let your products run to all users.
Unless you are using a framework that supports both iOS and Android (something like the Corona SDK) you won't have much actual code that will transfer over. Ideas, algorithms, logic, graphics, designs, etc will all transfer over just fine. Those are the hardest parts (IMO) of software dev.
Objective C (the language iOS apps are written in) is not that hard of a language to learn if you already know C-based languages (like Java). There are a few concepts that are different, but for the most part, it's not that bad. The biggest challenge for developing on iOS is buying a Mac. You can program for Android on Windows or Linux boxes, but iOS apps can only be developed on an Apple. Unless there is something that has happened in the Hacintosh arena that allows for iOS development on other platforms, you're stuck buying new hardware. BUT if you already have a Mac, download XCode and go to town!
Like Haphazard said, if there is enough money in it to make it worth your time, do it.
If you are getting paid, go for it! (Also, it could be a great learning experience.)
When I had to make the same decision, I considered the following criteria:
how much money is in the app on the other platform ?
how many times will this happen in the future, or is this going to be the only app? (how big is the benefit of learning the other platform for the future)
how much insider know-how is in the app that one is willing to reveal to another programmer porting this app (in my case I do mostly device handling apps, which is not really all that common)
what is the opportunity cost of spending time on porting an app instead of developing another profitable on the initial platform
If you have any possibility, you may look into similar apps and see how they are doing on the two platforms...
Good luck, whatever you are going to do...
I just learned about this and have not tested it yet, but one thing that you could do depending on the app you have you could take a look at PhoneGap. It looks pretty promising, though it may not work for your case with your initial application already made. But in the future this could help.
Unfortunately you will either have to re-write the app from scratch for iOS, or hand over the job to an experienced iOS developer. You can fairly easily port over the logic and computations in your app from Java to Objective C, but the user interface is the area where you cannot really re-use anything (except maybe icons), and the user interface tends to be a large portion of most apps.
As an Android developer who has ported several of my apps to iOS, I can say that this transition is a hard one. Firstly, you need to buy an iPhone and a Mac (if you don't already have these), since you cannot develop apps for iOS without the Apple hardware. Secondly, you need to learn how to use XCode and Objective C or Swift. And thirdly, since XCode ONLY allows creating the user interface graphically (as opposed to Android which lets you hand-edit the XML), there are many hidden things which can cause you to come unstuck. (UPDATE: Using the new SwiftUI approach to user interface design really helps with this last point, and in my opinion makes the transition from Android to iOS easier).
Finally the Apple and XCode environments seem rather alien to someone who is used to Windows and Android Studio. There are things like the Home and End keys having completely different behaviors to Windows which is frustrating. Also you have to use a combination of key shortcuts and mouse movements to hook up user interface elements to your code. Also, there are big annoyances such as the pop-up keyboard on iOS not pushing the content out of the way automatically like it does with Android. This is probably because Android is an OS designed for multiple screen sizes, whereas iOS is design for a limited number of screen configurations, but it makes iOS feel inferior and harder to work with from a developers point of view. (UPDATE: Using a ScrollView in SwiftUI solves the keyboard obscuring problem).
Although not really a programming question I believe many developers would have come across this and therefore give the best answer.
Currently I am developing an App for iPhone for the organisation I work for. Its close to release and there is heaps of interest when I present it but the occasional question comes up am I going to port it to Android. My answer is I would like to but according to web stats more than 90% of phones hitting our website are iPhones and the other 10% is declining (probably people migrating away from Blackberry, last count was 98% was iOS)
Now if you read the media many people would like you to believe that its a split market between Android and iPhone but this might be just in the U.S where the single carrier for the iPhone has limited its consumer uptake because all the information available to us (at least in my organisation) states otherwise.
I was curious to hear from other people who have looked into these stats both inside and outside the U.S because when I tell the person asking that there is no demand they dismiss it and say its growing, once again contradicting the stats available for our organisation.
I am really interested in Android dev so don't really want to hear that I should just make it to give people an alternative, it's hard to justify to management that I should spend their money to deliver content to 5% of our market. Currently it makes more sense to make a cut down web App rather than an Android App.
Be interested to hear your thoughts. Cheers
Honestly, I would argue it simply depends on your market. For instance, in my location Android users are increasing steadily. It still took us a long time to commit resources for development. Plain and simple, until recently, there wasn't enough return value to develop an Android app. If your Android market is only a small percentage of your market, then the resources would probably better be spent within your main competencies (i.e. for my company, developing more iPhone apps). It is easier to make a presence for a new app or upgrade in a market you are already established in. After creating the Android app, you would need to spend more resources on creating brand awareness, which if you already have a successful iPhone app, wouldn't be necessary if you simply created more iPhone apps. Also, let's be honest, the Android marketplace is a bit of a mess and hard to market on. Don't get me wrong, I have a healthy respect for Android and its capabilities, but unless you can see a return on the app, there is no point in developing it.
Depending on the type of application you are developing, it might be worthwhile to utilize a mobile framework that allows you to easily develop for both devices (plus many others). This is not the solution for all applications, such as those where speed is critical or games, but for many apps it might help. Have you looked at Appcelerator or PhoneGap? Just be careful to do plenty of research and make sure they support all of your requirements before jumping in.
It's difficult to answer your main question because the statistics related to mobile devices varies immensely, especially related to the type of application you are developing. Certain types of users prefer one type of phone and those users typically will use only certain features. For example, BlackBerry users are less likely to download games than iOS users.
For web apps
The approach suggested above is a nice approach because phonegap, appaccelerator or rhomobile do provide a sort of a virtual environment for applications developed in HTML, ruby. However, that might not be sufficient in a number of cases.
One of the approach i have seen developers adopt a lot for native apps
If you have developed your application using C code for the application state machine and lower levels then that code can be ported straight away to Android and be plugged into Android app using JNI technology.
The UI will have to be re-created.
What is the value to your organization of that 5% of customers being able to have a native Android app, versus the company's development time/resource cost?
Now that you've done all the app architecture and design work (including artwork, documentation, etc.) for the iPhone app, will a porting or rewrite for Java/JNI/Android take less development time by some multiple?
I think the most important factor is that if your company have the resources to maintain two version of the app. Would it be more beneficial to maintain native iOS app and a mobile version of the site? Since as you mentioned the usage of non-iOS devices of you website, as a metric lead a conclusion of such already.
As a matter of fact, if you have put most of the logic to the server back-end, writing an android app would not take anywhere longer than writing an iOS app, as long as you've programming experience in Java.
Also contrary to common beliefs, since the market share of Android phones are not as good in your place (would you mind telling us where your company is resided in?, it would in natural have less localized app in your geographical location. So creating an app specifically for them would gain more acceptance. That is fact, is a good thing. (see: Long Tail theory)
This just saves time.
Since I already have a web applciation.
I can just stick it inside a webview.
The question is: Does it turn off many users? How many users will be disgusted that the entire iPhone app is written in WebView?
I think it's pretty safe to say that most iPhone users are expecting apps to use the power of the iPhone, not just be a portal to a mobile website.
Think about facebook mobile compared to iPhone facebook app. If you're an iPhone user, I'm assuming you'd much rather use the app than a mobile version of the site (or mobile version of the site contained in a WebView in a an app).
That being said, depending on your app, if the mobile version of your app is highly usable, it could be okay...
Just my thoughts...
John Gruber on Daring Fireball just wrote about this today.
From a usability perspective, native apps usually feel better. They may also be more responsive and handle large amounts of data more gracefully. I have a few so-called "apps" on my devices which are just glorified Web apps, and they don't necessarily scream quality.
If you've already done your app, then just ship it. But keep your mind open to feedback from your users.
The answer is almost certainly "no". People care far more about the usability and experience of interacting with your application than what API-supplied widget you use to render it.
I read Apple has begun removing apps that are like this. Well technically, they remove apps they think could be easily implemented as a webapp instead. Yours obviously qualifies ;)
Source: http://techcrunch.com/2010/03/07/apple-cookie-cutter-apps/
EDIT: Apple seems to not mind, according to the Human Interface Guidelines:
If you have a webpage or web application, you might choose to use a web view to implement a simple iPhone application that provides a wrapper for it.
Of course, Apple has a tendency to contradict themselves. ;)
Apple human interface guidelines says this isn't even allowed. I forget where it comes from, but somewhere in the guideline it says apps that are only web views are not allowed. I'm about 95% sure I've seen this. Can anyone confirm?