We purchased the source code to a certain Android and iOS application and now need to re-brand it before releasing it on the app stores. I'm quite familiar with Android, so that side wasn't an issue. However, I've never touched iOS apps before, so I have a few questions.
On the Android side, we changed the application name by changing several string resources. Then we changed the package name in the manifest.xml file (to make this a unique application in the eyes of Google Play) along with changing the package names in the affected class files. And compile.
Would iOS applications require something similar? Is there an equivalent to the Android string resources where I can change strings in one place and they are reused throughout the application? Also do iOS applications have some sort of unique ID, the equivalent of the Android's package name in the manifest.xml file? If I change this unique ID, does it impact the code in any way (in Android the package name corresponds to the main application Java package that starts the application).
The package name you referred is called Bundle Identifier in iOS world.
It can be changed in Project settings, or directly in the project property list (.plist) in the Xcode project.
The original value may look like:
com.example.${PRODUCT_NAME:rfc1034identifier}
You can change it to whatever valid values you want (highly suggest you use reversed FQDN format).
Remember to clean & rebuild to project after changing this value, and all App ID, Provisioning Profiles and probably certificates have to be re-configured.
Related
I am developing an Android application named "English SMS Collection" in Google Play store, and now I want to upload this app in Hindi language also. So what changes are required to previous APK?
How to add another language to an Android application? And also what image size icons are required for uploading the app to market?
Any help would be appreciated.
Generally, splitting the same app into two functionally equivalent versions with different languages is a bad idea.
If you absolutely must do that, the only thing you need to change is the package name (package="com.example.project") in your AndroidManifest.xml (no need to rename actual packages, just that one string in manifest).
Also, if your Activities are declared relatively to app's package (e.g. .MyActivity as opposed to com.mypackage.activities.MyActivity) - and they most likely are - changing app's package name will obviously cause FCs because you effectively rename the activities. So to be able to switch the package name back and forth you'll have to detach Activity names from app's package by declaring them absolutely (e.g. com.mypackage.activities.MyActivity)
Here's a comprehensive guide on icons from Google, next time please do more research before asking such simple questions: Iconography
Also, judging by the question, you'll probably want to also read into this: Publishing Checklist for Google Play
Please DO NOT split your app up into two apks just because of the language. This is very bad style.
According to the android devleoper's guide, it's best practice to create ressource-folders with so called "configuration qualifiers". Your strings (e.g. text) should all be stored in the file /res/values/strings.xml . This is the default setup (without a configuration qualifier), when adding localized translations you have to create a new folder and strings.xml file /res/values-cc/strings.xml where cc has to be the standardized country/language code (e.g. "en" for english, "de" for german, "cs" for czech...).
For more (essential) informations on this, visit developer.android.com/guide/topics/resources/localization.html .
You need to change the package name because it should be unique while uploading in market. It can be signed with the same keystore file you have done for other two apps. Obviously, you have to change the Application name and its icon.
For more Information on Publishing Checklist for Android Apps, check this documentation.
In a Package Explorer, click on the package name (e.g: com.example.android), right-click and go to Refactor. Choose the Rename... option there.
I'm trying to find the best way to build/package an Android app for 6+ different customers. I could use different branches in SVN for all of the customers, but the only difference between the apps are some values in the resource folder (drawables, strings, etc).
I wrote an ant script that imports the standard Android build.xml. This script does the following:
Reads the customer names from a properties file.
For each customer the following is done:
The package name in AndroidManifest.xml is changed (by hooking into the -pre-build target).
The custom resources are copied into the res directory in the build (by hooking into the -pre-compile target).
The package name is changed back to the default value (by hooking into the -post-compile target).
The APK is copied to a specific location an named something like customer-versionno.apk.
This seemed to work well until I just now wrote the part that changes the package name. Because of the package name change the location of the R class is also changed, meaning that the build fails as the Java classes import the R class from the standard package.
I don't want to have a build script that changes code. I want to be able to do this with minimum changes to any files.
Soo..the questions are really:
Are there any good/simple solutions for my problem?
Am I approaching this problem in the wrong way? Are there better ways to easily package the same app to 6+ different customers?
Do you really need to change the package name? Changing the package name is a pain to do automatically. That being said, here is my solution to the problem:
My scenario is that I have one app that gets deployed to 30-200 different signed APK files where the only difference between the files are some resources (drawables, strings, values etc), and the package name.
I do this by working on a generic version of the app that serves as the template project. Once this works and I am ready to deploy I invoke a bash script that loops through the following steps for each target:
Clean the project completely
Swap out res dir and package name using sed.
Builds and signs the APK
This balances the horrific deply time with fast developemnt time. I really don't see another more elegant/robust solution than this.
And finally a small tip: In android manifest use relative package names like ".Application" instead of "com.mycompany.myproject.Application". This way you only need to change the package name in ONE location.
Is it possible to solve this with making 6+ different projects that includes your main projekt. This way you are able to override resources and make different apk's
I have been using apktool to decompile apps and make changes to better fit my touchpad.
One app in particular (swype) I would like to make a duplicate of with a different size keyboard I can switch to. I have tried changing in the manifest.xml any reference to com.swype I changed to com.thumbswype but when rebuilding the app it says some error about PathNotExist.
I also tried changing the app_name inside res/values/strings and while only changing this allowed me to rebuild the app It still wanted to overwrite the existing swype when I installed it.
The manifest is referring to class names in the compiled code, which would be in package comp.swype. So when you change the manifest but don’t change the compiled code, it can no longer find classes with the specified fully-qualified names.
And the Android system uses fully-qualified class names to identify installed apps. That’s why you can’t have two apps installed at the same time using the same fully-qualified names.
We service multiple clients. One feature we want to offer is an android application which allows the client to custom brand the application (icons, logos, names, etc).
Here are a few stipulations.
Customers of clients will use this app.
You could be a customer of more than one client, but we cannot show the user any kind of list of clients.
Clients cannot share a single app.
The app must be able to look different per client, even though the functionality is the same
Yes, I know it's a PITA to build it this way, but our clients don't want customers of other clients to know they are also our client.
So, what is the best way to build an easily brandable application with as little strain on the developer's sanity as possible?
Keep a separate res/ folder for each version of the app. Give every icon, logo and String the same name but tailor the content for each client, and build a different .apk for each by simply dropping that res folder into the build. I don't think you can make custom qualifiers work for this and just make a single .apk - and this would in any case bundle every client's custom pictures and Strings in to everyone's application.
I would start by developing a script for a global re-name, since you'll need that anyway (can be done fairly simply with find, xargs and sed)
You'll need tools for making the customizations to resources, that could be the SDK & Eclipse plug-in
Perhaps you could create some kind of wizard extending the Eclipse plug-in.
Or with a lot of work but easier usage, you could do something stand alone that drives the necessary command line tools to build the generated package.
You can do what #Jems said or (presuming that the app comunicates with a server) put the "logic" on the server side.
The first time you run the application the server will send you the resources corresponding to your client that you store locally.
Problems with this approach: The first time you may have to download a load of stuff...
Advantages: You just have to change a properties string saying which is the server, or the login to the server to know what it has to send changing the layout without having to deploy another app with different resources.
It really depends if you want to support layout changes on server side.
Build time solution using gradle could be achieved with productFlavors feature, described in http://blog.robustastudio.com/mobile-development/android/building-multiple-editions-of-android-app-gradle/
Flavors (aka customer brands) could be defined in build.gradle file in the following way (different package names are here to deploy each branded apk as separate application):
productFlavors {
vanilla {
applicationId "com.example.multiflavorapp"
}
strawberry {
applicationId "com.example.multiflavorapp.strawberry"
}
}
Specific android resources for brand could be then placed (instead of src/main/res directory) into src/vanilla/res or src/strawberry/res directories (in this case vanilla and strawberry are the brands). Please be aware that using productFlavors feature, gradle does no merging of assets, only simple replacing files without any knowledge about specific res subdirectories.
During building proces gradle creates build variants as combination of build type (debug,release) and productFlavor, more at http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Type-Product-Flavor-Build-Variant.
I made a lot of changes to my app : databases scheme, graphics, code, etc. The biggest is the package name that I renamed to a total different one. The applicatgio got the same name and Id in the manifeste.xml file and the apk got the same name, with the same digital signature.
Nevertheless, when using ./adb install -r myapp.apk, myapp appears twice in the menu. Of course since the DB is stored in a directory using the package name as name, the user feel like its data is lost.
How can I prevent this from happening, and if I can't, how can I automate he migration ?
I have several clues : prompting the user for uninstalling the old app, copying the database from the old file to the new one, etc.
The direct answer is the application appear twice because Android Market and Android OS view two different packages as two different applications. The code can be same, but if the packages are different the applications are completely different
Android Market identifies applications by their package name. I suspect this is because the OS tracks programs by package...makes sense that you wouldn't want two packages with the exact same name installed, how would the OS know which one to call? Therefore, if you install a package with the same name as a package that's already installed the OS will view it as a package upgrade and let the new program access the old user data.
You state that the packages share the same ID, I assume this is user ID. This enables you to share data between the packages. More information is here:
http://developer.android.com/guide/topics/security/security.html#userid
Recommendation: Release a small upgrade to your old package providing whatever glue is needed to let it share it's data with your new package. Then release your new package with the code to import the user data from the old package (need same UserId and signature). The transition would be seamless to the user (no manual backup and import).
The application signature must be the same. If you imported the project in another Eclipse, build it and upload it to market you will see 2 separate apps.