I am creating a iOS Static Library in Xcode. I will be distributing two separate binaries, one for running in simulators(x86 architecture) & other for devices(ARM architecture).
I am aware of aggregate target, but I want to know whether it is possible to write a script to check whether the code is running in Debug or Release mode, i.e in Simulator(debug) or Device(Release) in ideal scenario.
Depending on this, I can put some check in my respective binary to compile or not.
Devices do not run in debug or release. The user chooses to build their target in debug or release. You can supply a debug version of your library, if you'd like, though. That is something I have seen other vendors do, and is greatly appreciated by developers.
Related
Edit: Selecting Xcode in Finder, getting info, and ticking the box for Open using Rosetta makes things work, but surely there is a better way…
I have an iOS project with a static framework containing three variants in it; ios-armv7_armv7s_arm64, ios-i386_x86_64-simulator, and ios-x86_64-maccatalyst. I do not have any access to the source code for this framework and asking for a new build of the framework is not a practical option. As a result I need to work with the xcframework that I have in hand.
The framework works just fine on my colleagues machines as they are using Intel based Macs. As a new addition to the team I have been given an M1 machine. While I can build to a physical device, building to the simulator fails with missing symbols. This makes complete sense given that the simulator variant doesn't have arm64 in it.
Simply adding a new definition to the info.plist to cover the M1 chip doesn't work as that means there are two simulator definitions. (There are also other issues with this route)
If I duplicate the ios-armv7_armv7s_arm64 folder, add -simulator to the copies name, and replace the existing definition for the simulator framework with info from the ios-armv7_armv7s_arm64 definition I get an error about building for the simulator but linking in a file built for iOS. This means that no matter what I can't simply copy the existing M1 framework to get things going.
The only things I can think of both involve the need to somehow edit the M1 copy of the compiled framework so that it will work on the simulator, and I rather doubt there is a way to do that. If it is possible to do though I would then need to either come up with some nested framework trick that allowed me to have two definitions for the simulator but for two different architectures; or I would need to write a script that used uname -m to decide how to edit the framework's info.plist file (This feels very hacky, but would be the simplest way of making the project 'just work' on both Intel and M1 machines without the need to make manual adjustments and remember not to commit them.
Anyone have any brilliant ideas on how to get this framework working in the simulator without having a new copy built? (I haven't even found a clear method for how it would need to be built to work on both architectures.)
Xcode: 13.3.1
I've just developed my own (universal) framework with Xcode. When I import it into a test project (which definitely needs the classes of my framework), all runs well - both with the simulator as well as a real device (iPhone).
I've built a debug and a release version.
Under "edit schemes", I've also disabled "view debugging" within the release version.
However, when I set a break point into my source code of my test project (which - as mentioned - fetches some info from the release version of my framework), I can still step into the classes (.m files) without any problems.
As I want to deliver this framework to paying customers, I want to prevent anybody from seeing my source code while debugging. Experimenting with several flags in "build settings" had no effect ...
Any ideas?
nobody could help me, so I rookie had to help myself :-)
The solution could no bet easier:
just goto Targets -> Build Settings and then make a search for "Generate Debug Symbols" - arrived there, simply change form YES to NO
... and that's it!
Happy Frameworking :-)
I use the Crashlytics framework for crash collecting in iOS Apps.
When you use the framework, a "Build Phase" is added to your target that runs /Fabric/Fabric.framework/run <big-hex-blob> <another-even-biger-hex-blob>.
I'd love to know that these actually do – I'm not entirely happy with having external vendors' tools monkey about with my build, I'm old school like that.
Mike from Crashlytics and Fabric here.
The run script build phase is used, along with your <APIkey> and <BuildSecret>, to automatically handle the uploading of dSYMs so that you, and other developers, never need to manually upload one.
Similarly, the /Crashlytics.framework/submit command is used for distributions through Beta, our beta distribution service.
I have a iOS Swift app. I recently added a feature and uploaded the new version to TestFlight. For some reason, the main function for this new feature is not being called in release mode, but works perfectly in debug mode.
What I tried so far: within 'Apple LLVM 6.0 - Code Generation' for Release
1) Changed Optimization Level to None, and
2) Changed 'Symbols Hidden By Default' to No
I do not believe that the function's specifics matter here, but for what it's worth: it receives and manipulates some JSON data from the backend. I have ten other functions which do exactly the same thing for different types of data - not facing the same problem there.
Any ideas around this? What other differences are there between Release Mode and Debug Mode? that might be a good start to troubleshoot.
Thanks,
What other differences are there between Release Mode and Debug Mode?
Aside from different device architectures, there's a DEBUG preprocessor macro that is excluded in Release.
You can make a scheme that allows you to debug in Release mode, and check where it breaks.
Assertions will not run in release mode. Sometimes people make this mistake (I've made it a few times over the years):
assert(doSomethingImportant(), "Failed")
This works in Debug, but doSomethingImportant doesn't get called in Release.
I'm not really sure if this question is answerable as I am completely puzzled by this. Maybe if someone had a similar issue and can maybe point something out?
So I used 4 different CCParticleSystem effects in my app which run perfectly fine when built and installed from xcode. However, when I build and upload for testflight and download to my device, one of the CCParticleSystem effects doesn't show up with the intended particle texture, but instead shows up as a square instead of the texture I provided.
All 3 other CCParticleSystem effects are working properly though, just not this one, which is puzzling me.
I used Particle Designer for all 4 particle effects.
Anyone have any issues like this? Thanks for reading.
In my experience there are a couple of things that can cause issues like this:
There could be a resource missing from your build that was present in a previous build. Sometimes builds from XCode to device ignore resource deletions and updates.
You can check for this by doing an uninstall from the device, a clean in XCode, and then rebuilding to see if that makes the XCode build consistent with the TestFlight build.
If that doesn't help, then check the target membership of your particle resource and verify that it has been included in every build target that it should be (if you have multiple build targets).
Note that as a general rule, it is a good idea to do a clean within XCode prior to building an archive for distribution. This should ensure that the archive is always built using the latest sources and resource files.