0

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.

Cœur
  • 37,241
  • 25
  • 195
  • 267
footyapps27
  • 3,982
  • 2
  • 25
  • 42

1 Answers1

1

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.

user1118321
  • 25,567
  • 4
  • 55
  • 86
  • Maybe I'm not understanding the question. A developer can build their app in debug mode, but link against your release library, if they choose. If you supply a debug library, then they'd probably want to link against that when their app is being built for debug. But it sounds like you don't want the developer to be able to build in debug mode for some reason. Are you concerned about them being able to debug your library? If you only supply a release version, then they'll only be able to link agains the release version. – user1118321 Feb 15 '14 at 23:52
  • Ok, its something like I do not want the developer to by mistake switch the libraries & then link them in debug/release mode!! I want to stop this from happening. – footyapps27 Feb 16 '14 at 00:04
  • 1
    I don't know that's possible to detect because I don't think the linker has a notion of debug or release mode. It's just putting the already-compiled pieces together. It is possible to pass arguments to the linker, but it won't know whether the library being linked against was built debug or release (nor could you run a script based on that information if it did). But why be concerned about it? If the developer shoots themselves in the foot, it's not your problem! (It's nice to help them when possible, but there's only so much you can do.) – user1118321 Feb 16 '14 at 00:17
  • +1 for that, but the problem is my company does not want to get phone calls from users of the library, complaining that the code aint working!! Thus the question – footyapps27 Feb 16 '14 at 00:49