Looking for best practices for building localized versions of an iPhone app. Here are the specifics:
The code is 99% shared across the apps (no more than 2 or 3 different apps).
While most of the localization is about language, there will be some minor code changes as well.
The assets/app-icon-image will be different across the apps.
I do want separate apps up on the store. Ideally with their own release cycle (although not strictly necessary, I could release both every time the code changed).
What I DON’T want is one app that queries “something” at runtime, and then “figures out” it should use spanish, etc. I want users to be able to install one or more of these apps and have them coexist on the phone.
Different projects (and somehow sharing code)? Different targets? Something else?
Related
I have several iOS enterprise apps that had been developed years ago, and some of the earlier ones contain elements that Apple has deprecated, such as UIWebView.
My question is, after Apple has stopped supporting deprecated elements, will these elements continue to work in existing applications? Or will I need to go in and update the deprecated elements in all the apps in order to maintain functionality?
When Apple deprecates an API, it means that they intend to stop supporting that API in the future.
Sometimes this is because the API is no longer useful or is flawed (creates a security hole, for example), but it's typically because it has been superseded by a superior API and Apple is encouraging you to adopt the new API.
Existing applications running on existing operating systems will, naturally, continue to function.
When Apple is replacing one API with another they will typically maintain the legacy (deprecated) API for as long as practical. So your app is likely to run on at least the next few major versions of the operating system.
Apple also tries to avoid forcing you to choose a new API because that complicates development since you now have to support two APIs in your application if you want it to be compatible with earlier versions of the OS. (Of course, if you want the features of the new API today, you don't have many choices: either support both APIs or limit the OS versions your app can run on.)
How long is on a case-by-case basis. A security flawed API might be removed in the next OS. On the other end of the scale you have string encoding APIs that have been deprecated for almost a decade (because they can't properly handle all Unicode conversion cases), yet they are still included in the framework and still function as advertised.
On high-profile classes like UIWebView, I would expect it to continue to work for years to come, but it won't be improved or get any of the new features of WKWebView. So, over time, it will look and act more and more dated. How important that is to your app is a subjective decision for your development.
I believe it depends on the user's OS version on their device. If the OS no longer supports the deprecated elements, then you may notice an error similar to the one below:
"[Appname] needs to be updated"
I am hoping that someone could help answer my question.
Problem
I am looking at developing an iOS application that compromises of smaller portions/functionalities (lets call it mini apps just for understanding better). I am looking for guidance on how I should approach this problem to ensure that there are no potential errors in the future. Just to give you a background of my problem, I will run through some of my approach.
First Approach
My initial approach was to develop and release a bunch of apps that can talk to one another. But since iOS apps can only inter-communicate with URLScheme, and which is not sufficient enough for me, I decided to revisit later and look for better solutions.
Second Approach
I also looked at making the apps have a common local database, but since iOS apps are restricted only to their sandbox, this again won't work.
Third Approach
The third approach was to have an app talk to a webService and back again to the other app.
Current Approach
So instead of having a bunch of apps installed on a device that can talk to one another, I am now looking at going with the approach of having only one master app that has different portions/functionalities.
My problem is figuring out how to properly manage my files that are specific to the different portions/functionalities/mini Apps, so that I could independently push a portion updated files to the app and not have it corrupt the other portions.
Would it be a good idea to create a subfolder in the app Document directory for the different portions of the app? Are the other approaches feasible?
I am looking for your help, approach and feedback in tackling the problem.
Thanks
How to go about designing a multi-platform app that offers In-App-Purchase?
I'm working with JUCE (Win/OSX/Lin/iOS/Andr).
I know that iOS allows IAP. So I'm guessing OSX also does. I would suspect Windows and Android also provide something similar. I doubt Linux provides anything as it is decentralised by nature.
So maybe I would have to write 4 separate IAP modules, and maintain 4 separate stores. Yuck! I don't want to do that. I recoil from duplication.
Is there any way to unify IAP across these different platforms?
The ideal solution would be single store to maintain, and a single C++ API to access it.
But is this even possible? I think Apple explicitly forbid any kind of store/monetising outside of their system. But http://soom.la/ seems to provide some work around for Unity3D.
The api will be same, but the platform specific functionality has to be separate. This way you have one repository and for a given platform build, pull the required code. Here is an example "Upload XML data to MySQL or NoSQL"
We currently have a .NET SaaS web app with individual deployments per customer. We are on a monthly release schedule and each customer is upgraded to current releases on independent schedules. Sometimes a certain member might even skip an entire release, upgrading on the subsequent release.
We are looking to develop a native iOS application and are trying to figure out the best way to keep a single iOS codebase in sync with multiple supported server-side deployments. I know that Citrix ran into this with GoToMeeting because at one point there were multiple versions of their native app in the App Store to satisfy customers with a variety of server-side versions. Supporting multiple releases corresponding to currently supported server-side deployments in the App Store is not an option we are considering. We have discussed having conditional branches in the code to check which version of the server-side code the customer is using and disabling more current code and features for those users, but this isn't ideal either. Certainly others (such as Citrix) have run into this and have come up with cleaner solutions so I thought I'd cast my net and see what responses I could get. Any help or suggestions greatly appreciated.
Thanks.
When dealing with differences in API versions I would think a configuration file on your iOS app is essential. By configuration file I mean a plist or just settings download that fires when the app runs and tells it where to go for api's. This lets you do what you need with other api versions and when you are ready you can just change the configuration and point it at new versions.
I understand that iOS 5 is the latest (and the greatest) version of the Apple Mobile OS. I also know that it contains ARC, OpenGL ES Debugger yada yada yada...
I have already developed some in-house apps at my company and they all work perfectly fine. But as a developer, should I really bother upgrading all my apps to be iOS-5 compatible? If so, why?
"Upgrading" doesn't really apply to apps, only the OS. If your app already runs fine on iOS 5 (ie is "compatible"), which it might well be, there's no reason to change it.
If it's not currently "compatible", implying that you've tested it and something in the app is broken when run on iOS 5, then you would consider fixing or working around those issues so that your users on iOS 5 can use your app.
If these apps are ones that you're continuing to develop, you'd consider whether using the new technologies (ARC, new frameworks, etc) is worth the trouble of doing so and/or dropping support for older devices. That's a tradeoff only you can make relative to your apps and your business needs.
Considering that majority of crash related problems are due to memory allocation/deallocation/reference errors, it might be helpful to port the code over to use ARC. Of course the time/cost will need to be determined to see if it's worth it.
Do a cost benefit analysis.
Would an update building with the iOS 5 SDK benefit your customers by fixing existing or probable bugs, adding iOS 5 features, or providing other opportunities to just make a better product? Would an update provide you or your company with an additional marketing opportunity? At what cost in development, test and QA time?
Perhaps it would be a long term advantage in helping keep your development skills more up to date on the new APIs and tools (such as ARC).
But there's also an adage: If it ain't broken, don't "fix" it.