I'd like to define a default folder name on home screen for my apps (which are Ad Hoc distributed), such as the default apps when they are dragged to ("Productivity", "Utilities", "Games", "Navigation"):
Instead of default name "Folder":
How can I achieve this?
Edit:
I tried adding LSApplicationCategoryType to Info.plist, but that doesn't seem to affect anything.
I think this will work only on AppStore versions. I tested with bunch of my Ad-hoc releases and their AppStore releases. - For ad-hoc releases - "Folder" name appears. For AppStore versions - App, which is moved onto other app - it's category name is used. (In case Ad-hoc is moved onto AppStore app, then AppStore app's category is used).
Anyways, I checked out that LSApplicationCategoryType https://developer.apple.com/library/ios/documentation/general/Reference/InfoPlistKeyReference/Articles/LaunchServicesKeys.html#//apple_ref/doc/uid/TP40009250-SW8
Did You use for example for "Education" - public.app-category.education ?
Either way - it might not even be intended to work on debug/ad-hoc releases as stated in the same page:
LSApplicationCategoryType (String - OS X) is a string that contains
the UTI corresponding to the app’s type. The App Store uses this
string to determine the appropriate categorization for the app. Table
2 lists the supported UTIs for apps.
...which sounds like, that this value is used by App-Store, to correctly set Applications category, which then is used to categorize applications on springboard.
So I guess, this will work only when App is downloaded from App Store.
Related
I am taking over an IOS legacy product written in Objective-C.
Say, the product is called Foobar.
To run both the old version and the new version on the iPad, I first called our version of the software "OurComp Foobar".
After a while, I was able to present it to our customer and named it back to "Foobar".
Now, when I look at the settings in the IOS user settings, our application is still listed as "OurComp Foobar". I found this after I added some settings which appeared there. Deployment to this device always takes place from xcode directly to the device.
I have grepped through the entire source directory, looking for the string "OurComp", but it doesn't appear anywhere.
I guess it is linked to the bundle id etc. - but where would I have to change it back?
Once the software will be available to the public, we want to present it as "Foobar", not as "OurComp Foobar".
Note that this is a question on software development, not on jurisdiction. We are developing the software on behalf of the client.
The only user facing app name is the CFBundleDisplayName, which you set in the Info.plist. The name on the App Store is a different name and is set via App Store Connect.
I have developed one iOS app but I have about 10-13 clients whom I will be selling this app. So, the app is one and I will just change the name on all apps and publish it from same account. Is it allowed by Apple? The source code will be same and the name will be different on apps. The app is built to sale copies to client so it is allowed?
It is possible, but Apple won't be happy about it, the proposed way to do this is to license your apps to the clients instead of placing them on the public app store.
Source: https://forums.developer.apple.com/thread/7825
Apple does allow one App with different names for different languages.
https://developer.apple.com/internationalization/
So you might use a little trick, where you only "translate" the name of the app and leave everything else as it is.
Yes you can submit the same app with different name.
You just need to create the different targets of the same app. Bundle identifier will be different but the source code will be same.
Here is the link for guiding of target creation-
Multiple target creation
I'm fairly new to iOS development and I am porting an Android app to iOS 7. The Android app provides a screen that allows the user to change a number of non persistent settings. Because these are not saved, it doesn't seem appropriate to me to expose them, on iOS, as preferences via a settings bundle and the built-in Settings app. So I'm looking at an in-app settings screen, which I understand is allowed - but perhaps not encouraged - by Apple.
Some questions:
Am I correct that an in-App approach is allowed by Apple? Most example code seems to use settings bundles. Am I going to have problems when the app is submitted to the App Store?
I can put the settings UI in a simple UITableViewController, but is there an approved way to expose this to the user? XCode 5 doesn't provide a settings identifier (and icon) for toolbar buttons, and the "Info" identifier (letter i inside a circle) seems to have been dropped too. Should I use a custom icon? Are there any de facto standards?
I haven't seen this kind of UI element before on iOS but my exposure to the platform as a user is limited.
There is nothing wrong with doing an in-app preference (table)view. You won't be rejected for that (this point seems to be way too much exagerated outside the iOS community). There are guidelines that you can follow: iOS Human Interface Guidelines... or not. As long as you don't use private APIs (assuming you know how to access them anyway), you're fine! So you can use a custom icon, the "i" button, or any UI element that convey the reasonable meaning of providing access to more info/preference.
In your code, you can use the class NSUserDefaults (with the standardUserDefaults) to store your preferences.
Many apps have in-app settings. It's fine. Apple even states that it is fine. Just don't have both.
Use a custom icon. Many apps seem to use an icon that looks like a gear.
I want to have two version of the same IOS app to stay in the same time in the same device, one for testing and the other for production.
The app is built using phonegap build, so what I have done is
using two different bundle id specified in build.xml (edit: config.xml), so that one is dk.xxxDev.mobile, and the other one is dk.xxx.mobile
having two different apps in the apple developer page, so now I still have the previous one for dk.xxx.mobile and the new one dk.xxxDev.mobile
building using two different provisioning file, one for each app (one is using a developer profile, while the other is using an ad hoc certificate, but i guess we don't care about it)
Still, every time I deploy using itunes or testflightapp, one app overwrites the other one! What am I doing wrong?
edit: I Also changed
- the tag "name" in the build.xml (so that testflightapp can distinguish them )
- I'm using different filnames when I add the app to iTunes
Can you check if the 2 versions of the app generate are using the same IPA file name?
The file naming convention for the Mpbile Apps is as follows:
app_name.version.IPA file
iTunes in the Mac or in the PC store the mobile apps in IPA format and if they are using the same name, installing one will override the other. This is a valid question for Apple Support and this is something that a future version of iTunes may fix.
I was doing something different from what I wrote, I was probably using the same certificate for both versions.
So doing exactly what I wrote, it is supposed to work.
You need to change bundle identifier of one of the apps
Select Project in Xcode, then select target and in general tab you will see bundle identifier string.
e.g. com.YourCompane.AppName change "AppName"
I have a base project, which I would like to re-brand and resell for clients. So my question is: When I branch and create a new project obviously it needs to be a separate entity from the main. Is the only thing that separates these apps during submission the Bundle ID?
Since renaming projects can sometimes be a pain, what I'm doing is:
Creating the branch
Opening it in XCode and changing the Target name, and this changes the bundle ID because it's set to com.whatever.${PRODUCT_NAME:rfc1034identifier}.
So I'm wondering when submitting a new project, is the bundle ID the only thing that needs to be globally unique? or are there more attributes that I would need to change for each new branch/project?
Thanks
From my experience, only the bundle ID needs to be different.
A few things you should notice though:
You probably want the app splash screen / icon / icon label to be different between clients too
Under Build Settings your Code Signing Entity might need to be different too. If you have certificates+provisioning profiles which are specific to the bundle ID, you would have to create new sets of those for every client and use them when building
If you see that you're starting to change resources (like the icon / images for branding / string tables) between clients, using multiple projects and a shared static library may be easier for you. Take all of your shared code and convert it to a static library iOS project, and then create a separate project per client (normal iOS app project) which uses this library. This way all the metadata (like bundle ID, certificates, icons) can be different, and the code be the same.
If your app defines any URL schemes (for example, if you implement login with Facebook you need to do this), these schemes should be different between clients too. If they are the same, you are bound to have collisions when a user installs 2 apps on their device.
And one last tip regarding Apple policy:
If you are planning to submit all of these client apps under your developer account, this may be against Apple policy and your apps might be rejected. Apple wants you to open a dev account (and pay the $99/year) per client..