This is a very noobie question, but I can't seem to find any specifics on it from searches.
For my iOS app, do I manually increase the version and build numbers myself from the "General" tab in xcode, or is it done through the code signing or what?
Updating it myself seems simple, but I feel like maybe thats not what I'm supposed to be doing.
Thanks
You assign manually from Xcode itself and even if you want it automatically then also it is possible
This numbers are just for unique identification on app store, so every time you need to change the version number from previous one
You can go through this link
https://developer.apple.com/library/ios/technotes/tn2420/_index.html
For automatic increment use agvtool
visit https://developer.apple.com/library/ios/qa/qa1827/_index.html
Related
well, I have my Xcode project done recently, which is a "promising" iOS app, and need to be evaluated by my boss in order to apply for a development group. But, no wonder, bosses are always, u know, lack of "professional" skills. I even cannot assume them to have an xcode compiler on his computer.
But, I need to present what I have done in a intuitive way. I have already finished a "project report", and I have to hand them in together with my project codes. well, that's the rule, and I cannot stay with my bosses to explain "how to open the file"..
So, I am wondering if there is a more simple way to show them the app. luckily, I can burn a CD to store the things they need. However, obviously, I rank "give them a Xcode install file" as the least choice.
Is there any better way that I can show my work? i.e. provide an iOS Simulator with that app pre installed? how could that happen? or any way else?
by the way, I have tried to upload it on App Store, but failed. Since it is just a raw beta version (too ugly to be listed on Store, as Apple explained). And I have heard that I can use "Enterprise Distribution" to skip App Store check. But, I cannot have an "Enterprise license".
I am finishing up my first application and researched some methods to make use of two targets in the same project. There are few functions that will reduce the free version and will add adbmob banner.
The various tutorials that follow, the one who worked to differentiate the targets was this:
How to get Target name?
I researched other ways to accomplish this task are old threads and could not make it work.
I tried to add in FREE_VERSION Precompiler macros and many errors occurred. I also tried to add FREE_VERSION in Other C flags within LLVM 5.1 - Custom Compiler flags.
I'm not sure if these methods still work, or if there are better. Does anyone have a more current way to accomplish this or can I use the method I quoted at the beginning of the topic?
You can use a Preprocessor macro to mask off code that should run only in one version or the other, and you can use User-Defined Build Settings to differentiate important fields in your app's property list. Just make sure you produce archives for each version while in the correct build scheme when you're submitting.
However, Apple is becoming less friendly to "upselling", so if your free version asks the user to consider downloading the paid version, it will likely be rejected (they will cite guideline 2.9). To avoid that, you can either make a single version which is free and upgrades with an In-App Purchase, or you can be careful to make sure that the free version doesn't push the user toward the paid version.
Similar questions have been asked before, but I can't find the specific details I'm looking for. I have an Xcode project which has been completed and submitted and is on the App Store. I want to make a similar app for release in a different country. To avoid complications, I want to use a fresh project in which to make the changes. I intend to make a copy of the original project, tweak it, and then release it (this is not about language so localization is not the answer).
Because Xcode is doing so much complicated stuff under the hood, and because I'm unsure of exactly which details are being validated when submitting to the App Store, I don't know which details I need to change to ensure two separate projects on my Mac and two separate apps in iTunes Connect.
Obviously I will need new provisioning profiles for the new project. What else do I need to change once I've duplicated my project? The bundle identifier maybe? Anything else? Any advice much appreciated.
The thing that must change between projects is the application ID (or bundle identifier, as you called it).
And yes, when you change the application ID, you do need to create new provisioning profiles to go with it.
If you're feeling really ambitious, you can use the exact same project as your original one and merely create a new target (and application). That way any code changes you make to one can be picked up by the other and the differences would be the ID and maybe the localizations/resources used in each app. Here is a related question that talks about that.
I have a bit of a dilemma — no matter what I do, I cannot get Apple's Instruments.app to symbolicate any of the included instruments while I'm profiling on my devices (it works OK in the iOS Simulator).
I've tried just about everything I can think of, including:
Checking that I'm actually building a dSYM
Switching between Debug and Release build schemes
Making sure that the signing certificate being used in my Development cert
Adding and removing my Derived Data folder from Spotlight's Privacy list
Clean & Build before profiling
Removing the Derived Data folder before building and profiling
I'm not sure where to go from here — I had symbols for an hour or two earlier in the week, but I just can't get them to show up at all anymore. It would be great to figure out what the mystical incantation is to make Instruments always find my app's symbols.
In the File menu there is an option for Re-Symbolicate Document. Choosing this, you can find your binary in the list and use the Locate button to specify the location of the dSYM manually. There is also a checkbox here for using Spotlight to find the dSYM; it's possible it got deactivated if Spotlight was borked at some point but is now fixed.
It seems that you cannot do this while Instruments is actually instrumenting, but it does seem to keep the setting for the next time you hit Record. It does not, however, seem to remember the setting after you close Instruments.
Did you ensure you are signing the app with a development profile (as opposed to a distribution profile)?
Be aware that you are usually using release builds with instruments so make sure you didn't choose a distribution profile for your release configuration...
I've seen Instruments 4.2 fail to symbolicate several times with the correct dSYM file.
After saving and quit/restart Instruments, it will then symbolicate.
(Sometimes I'll capture a small sample and make sure it works before collecting large samples.)
Aside from xcode's tools, you can use atos: https://stackoverflow.com/a/4954949/312725
Be sure to take slide into account as well: https://stackoverflow.com/a/13576028/312725
(I'm adding this information to several related questions that are related to that, but aren't exactly duplicate questions. This is copy-pasted, it's a honest attempt to help someone who googled that question rather then spam.)
I've developed and application for iPhone. It works fine on os4 but it does not work on os3.1. In fact works but there are some problems; after splash screen a what screen appears. while I leaving the application I can see the application is opened successfully but just see while exiting.
So I wonder if there is a tool which says which apis have problems with os3.1? So I have a chance to replace them.
If you want to check a specific API, just run this in your code somewhere with an appropriate response. For example, to see if print is supported, run this...
if (NSClassFromString(#"UIPrintInfo")) {
}
Set your project's Base SDK to iphone-os-3-1, then build. All the error messages about classes, methods, and functions that don't exist must designate things added since iphone-os-3-1, since your project built and linked fine against the iphone-os-4-0 SDK.
If you don't have the iphone-os-3-1 SDK, try this instead:
Open your project's Build Settings.
Find the "Preprocessor Macros" setting.
Edit it and add __IPHONE_OS_VERSION_MAX_ALLOWED=30100
Now, try building. This should cause everything introduced after iOS 3.1 to be labeled unavailable, producing the same errors as if you had switched to the iphone-os-3-1 SDK.
It's a good idea to get a second installation of Xcode for this situation, in this case you need 3.2.1 with SDK 3.1.3 - I wish I could help you with a download link since it is no longer shown on Apple's page, but I have googled in the past and found direct, official download links which will work as long as you are signed in with your developer account, so good luck.
The annoying bit is that you need to go through your project files and set "Base SDK" to 3.1.3 and then back once you have completed the exercise. But it is the easiest way to flag what you can't do in 3.1.3. "sudo rm -rf" (I feel nervous even typing that) has an excellent method there but you need to have an inkling of what might be safe and what might not before you implement it or else you end up with code 10x the size it needs to be.
Apple really needs to sort out this issue - hopefully by flagging methods that are prior to your specified "Deployment Target", in the same way that deprecated methods are flagged.