I'm trying to create a way to be able to distribute a beta version of my app via Testflight without overwriting the production version. I'd like to be able to know in the code whether it's a beta build or a production build (i.e. somehow define #if BETA_VERSION, similar to the global DEBUG variable), and I'd like to be able to differentiate it with a separate app icon on the springboard, as well as a different app name (i.e. MyApp Beta or similar).
I set up a beta configuration by duplicating my release configuration, and I already have a provisioning profile for AdHoc builds (I've been distributing via Testflight for the last six months or so). I know that to change the app name I need to change the bundle display name property in the project's plist file, but I'm not really sure how to make a separate "profile" to hold all of these changes.
I've tried reading through this article, but I couldn't get it to work and I inadvertently messed up all my provisioning profiles when going through the instructions.
I've been struggling with this for a few weeks now. The details of this process are pretty opaque, so any detailed instructions or pointers are particularly appreciated.
Thank you in advance!
PS it probably doesn't help that I'm really confused about the relationship between targets, schemes, and configurations in Xcode.
I use three configurations in my project: Release, Beta and Debug, where Beta is a duplicate of Release. In each of the three configurations, I'm including the following in my target's build settings:
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) CONFIGURATION_$(CONFIGURATION)
What this will do is define a separate preprocessor macro for each configuration. In your code, you can then do the following:
#if defined(CONFIGURATION_Beta)
// Something that should only happen in Beta builds
#endif
You can define additional build settings per-configuration in the “User-Defined” category (at the bottom of the build settings in Xcode), and then reference them in your Info.plist file. For example, you could define a custom BUNDLE_ID build setting that's different for Release, Beta and Debug builds, and then set the value of CFBundleIdentifier in your Info.plist file to ${BUNDLE_ID}, which would allow you to install Release, Beta and Debug builds side by side on your device.
Update:
If you want to see a good example of how to set all of this up, check out the project configuration in Cheddar for iOS.
Related
I am a new guy in OC programming. Now I am involved in a framework development project.
I know the framework works as a library, which contains a group of methods. It's not an application that can run on devices.
Actually, our framework will work with customer's application. We want to investigate what happened inside our framework when customer's application crashed. So I want the 'DSYM' file of our framework, instead of an application.
As far as I know any iOS application does have corresponded 'DSYM', but I didn't find the 'DSYM' of our framework.
Does iOS framework project have 'DSYM'? If it does have, how can I obtain it?
By the way, I am using Xcode 8.1.
Thanks!
According to my observations, .dSYM files are generated for iOS dynamic framework built with Release configuration only.
After build succeeds, the debug symbols files can be found at these paths, for a device and simulator, respectively:
<Build_Root>/build/Release-iphoneos/<Product_Name>.framework.dSYM
<Build_Root>/build/Release-iphonesimulator/<Product_Name>.framework.dSYM
, where
<Build_Root> is usually a subdirectory within Derived Data directory;
<Product_Name>is the name of your framework.
Yes, you can generate dSYMs for dynamic frameworks. There are a few relevant build settings that control whether and where these files are generated:
DEBUG_INFORMATION_FORMAT = dwarf-with-dsym,
DWARF_DSYM_FOLDER_PATH = "$(CONFIGURATION_BUILD_DIR)",
DWARF_DSYM_FILE_NAME = "$(PRODUCT_NAME).dSYM"
Obviously, you can set these to whatever you want, either in your project's build settings in Xcode (the project.pbxproj file) or as arguments to xcodebuild (depending on how you generate your framework).
DSYM (Debugging SYMbols) files generally store the debugging symbols for your app. And if app crash any where symbols replaced with appropriate method name so that it could help developer in a readable form. And for that you can use the crash log and they can be find in the iPhone where the app is installed. Each app and device have their own crash log.
Also please check this link it might help you.
Read Crash Report
Upload Symbols for iOS Framework
Hopefully these might help you or guide in the right direction.
I just realized the tensorflow has supported ios now. But how to compile the example in contrib/ios_examples directory?
thanks!
josh
We're still finishing off all the documentation, but here's a draft of the README I'll be adding to the ios_examples directory. I'd be interested to hear if this helps, and if you have ideas for improvements.
TensorFlow iOS Examples
This folder contains examples of how to build applications for iOS devices using TensorFlow.
Building the Examples
You'll need Xcode 7.3 or later, with the command-line tools installed.
Follow the instructions at tensorflow/contrib/makefile to compile a static library containing the core TensorFlow code.
Download Inception v1, and extract the label and graph files into the data folders inside both the simple and camera examples.
Load the Xcode project inside the simple subfolder, and press Command-R to build and run it on the simulator or your connected device.
You should see a single-screen app with a "Run Model" button. Tap that, and you should see some debug output appear below indicating that the example Grace Hopper image has been analyzed, with a military uniform recognized.
Once that's been successfully run, make sure you have a real device connected and open up the Xcode project in the camera subfolder. Once you build and run that, you should get a live camera view that you can point at objects to get real-time recognition results.
Troubleshooting
If you're hitting problems, here's a checklist of common things to investigate:
Make sure that you've run the download_dependencies.sh and compile_ios_protobuf.sh scripts before you run compile_ios_tensorflow.
Check that you have version 7.3 of Xcode.
If there are Eigen errors, look inside the build settings of your Xcode project. In the Search Paths section, you'll see an Eigen include directory that changes with each version of the framework. You may need to update this to may the version in your tensorflow/contrib/makefile/downloads folder.
If there's a complaint about no Session's registered, that means that the C++ global constructors that TensorFlow relies on for registration haven't been linked in properly. You'll have to make sure your project uses force_load, as described below.
Creating your Own App
You'll need to update various settings in your app to link against TensorFlow. You can view them in the example projects, but here's a full rundown:
The `compile_ios_tensorflow.sh' script builds a universal static library in tensorflow/contrib/makefile/gen/lib/libtensorflow-core.a. You'll need to add this to your linking build stage, and in Search Paths add tensorflow/contrib/makefile/gen/lib to the Library Search Paths setting.
You'll also need to add libprotobuf.a and libprotobuf-lite.a from tensorflow/contrib/makefile/gen/protobuf_ios/lib to your Build Stages and Library Search Paths.
The Header Search paths needs to contain the root folder of tensorflow, tensorflow/contrib/makefile/downloads/protobuf/src, tensorflow/contrib/makefile/downloads, tensorflow/contrib/makefile/downloads/eigen-eigen-, and tensorflow/contrib/makefile/gen/proto.
In the Linking section, you need to add -force_load followed by the path to the TensorFlow static library in the Other Linker Flags section. This ensures that the global C++ objects that are used to register important classes inside the library are not stripped out. To the linker, they can appear unused because no other code references the variables, but in fact their constructors have the important side effect of registering the class.
The library doesn't currently support bitcode, so you'll need to disable that in your project settings.
I have a CodePush app that has three deployments: testing, staging and production.
I have different app builds that align with these:
A build that does out to testers (testing)
A build that goes out to a group of preview users (staging)
A production build (production).
How does CodePush know what deployment it should be sending to a build?
And how do I set up my app to make sure the right build (e.g. staging version of app) is getting the right deployment (e.g. staging deployment in CodePush)?
The CodePush server knows which deployment you want to query for updates against based on the deployment key which is configured in the config.xml file or is passed to the call to sync (with the later taking precedence). If you want to generate three separate builds for QA/staging/production, then you simply need to make sure you update the deployment key that is set in your config.xml file before running cordova build to generate the APK or IPA file.
Unfortunately, Cordova doesn't really have a standard way of defining multiple environments, which would allow you to add your per-environment keys to the config.xml and have the right one be selected when doing an environment-specific build.
Depending on how your app is structured, you could also skip the config.xml file completely, and just pass the deployment key directly to the call to sync(). Then, you just need to make sure your app defines all the neccesary keys in a config somehow and loads the correct one for each build. You can take a look at this starter project for an idea of how this could be generally done.
I have configured CodePush for my dev, test and prod environments. But my application is a react-native one. I think the same will works for Cordova as well.
The important point is CodePush identify particular app by it's CodePushDeploymentKey. First you should create 3 channels on AppCenter for dev, test and prod. Then setup CodePush on those 3 environments and Get relevant CodePushDeploymentKeys.
Then you have to add those 3 keys for 3 different targets on your app. For iOS you can create 3 different targets on Xcode with 3 different plist files and add those different CodePush keys in relevant plist files.
For android you can create 3 different Product Flavors for dev, test and prod and then add DeploymentKeys on each flavor.
In this article I have explained everything step by step with all the screenshots and links.
It's getting quite frustrating with Xcode 5 here. All I'm trying to achieve is embedding some custom Cocoa frameworks into my project and create two versions of the app, one for the Mac App Store and one for a custom Online Store (so that when building for the MAS there'll be a folder called Debug (MAS) so I can distinguish it from the other version).
I embedded three frameworks into the project (only god knows why only one project can have another one embedded at a time, to hell with this limitation) and added their products in the "Link binary with libraries" and "copy frameworks" build phase. The finished built products are at the default location in the Library.
Now here's the thing - every time I'm using custom build configuration files other than "Debug" and "Release", the frameworks are NOT copied to the custom build folders but instead just go into "Debug" and "Release" regardless of any build options of the main app. Also, the frameworks are always built using "Debug" and are no longer connected to the current build mode (test, archive, etc.). To cut a long story short, this is a huge mess with file paths and obviously a lot of bugs concerning custom frameworks and custom build configurations.
Now my question is - there has to be an official or working way of maintaining an Xcode project that is both distributed over the MAS and a custom online store (two versions) and has at least one custom framework embedded. How do all other developers have solved this problem, I feel like I'm doing something fundamentally wrong and if I do, sorry for putting the blame on Xcode but something's for sure: Xcode's path management with external components is a chaos and the cause for unlimited mailing list and forum posts...
The answer is to create separate targets for the MAS & non-MAS app. You can add additional targets to build the custom frameworks and make the different targets dependent on each other (as necessary). Once this is all setup (properly) then building any of the targets will build any dependent targets (with the same build flags). And AFAIK there's nothing preventing an Xcode project from including multiple sub-projects so I haven't a clue why you believe this to be the case.
I have a really annoying problem. My app is published in the AppStore.
Everytime i run the app from Xcode, the iTunes binary just gets overwritten... and next time i need to test something with the production version of the app, i need to re-download it.
Is there any way to solve this?
Thanks in advance!
You need to change your bundle identifier. Here's how I set it up in my projects
Select your Project
Select your target
Navigate to the Info tab
Change the bundle identifier to a custom build setting e.g. I have it as ${BUNDLE_IDENTIFIER}
Now click on Project - (you may wish to keep at target level your choice)
Navigate to the Build Settings tab
Scroll all the way to the bottom to see User-Defined
Click Add Build Setting
(1) Select Add User-Defined Setting
(2) Add Key as the name you chose earlier
Set a different bundle identifier for each scheme
Bonus
You can use the same trick for icons so you can easily tell apart your builds on one device
Changing the bundle identifier, as Paul.s suggested, works — but it means your Release and Debug builds will diverge. Technically they will be different apps that use different containers. There can be good reasons to do this, but it has it's risks too: it's a bit more complicated, and you usually have to work a little harder to make sure you test that the development version properly handles data from the production version. You'll want to make sure any ad hoc builds you send to testers use the production bundle identifier.
Another way to approach the problem is to streamline installing the old version. If you Archive your production builds, then you can install them without downloading them again through the App Store. Just open-up a previously exported IPA and sync.