Running ios_application

[Indigo Orton]

Hi all,

I've managed to get an iOS application almost completely migrated to Bazel. However, I'm running into a problem with running the application.

Two things:

1. When I bazel run the ios_application rule (without passing any cpu flags) I get an error:
   

   iossim: ERROR: Invalid SDK version: 8.1

   Supported device/SDK combinations:

    -d 'iPhone 4s' -s '8.3'

    -d 'iPhone 5' -s '8.3'

    -d 'iPhone 5s' -s '8.3'

    -d 'iPhone 6 Plus' -s '8.3'

    -d 'iPhone 6' -s '8.3'

    -d 'iPad 2' -s '8.3'

    -d 'iPad Retina' -s '8.3'

    -d 'iPad Air' -s '8.3'

    -d 'Resizable iPhone' -s '8.3'

    -d 'Resizable iPad' -s '8.3'

   ERROR: Non-zero return code '3' from command: Process exited with status 3.

   
   However, I have set --ios_sdk_version to 8.3, so I'm not sure where it is going wrong.
2. When I bazel run the ios_application rule passing armv7 or arm64 or both I get the error:
   

   ERROR: Loading of target '//tools/objc:default_provisioning_profile' failed; build aborted: no such target '//tools/objc:default_provisioning_profile': target 'default_provisioning_profile' not declared in package 'tools/objc' defined by /Users/indigoorton/Documents/Github/Master/Master/tools/objc/BUILD.

   ERROR: Loading failed; build aborted.

   The rule doesn't appear to be in the Github version either (i.e. it isn't my out-dated version, and I've pulled and tested while writing this).
   
   

NOTE: Here are the flags I am passing in on all run and build calls (from .bashrc):

build --ios_sdk_version=8.3 --cxxopt "-std=c++11" --linkopt "libc++" --conlyopt "-std=gnu99"
run --ios_sdk_version=8.3 --cxxopt "-std=c++11" --linkopt "libc++" --conlyopt "-std=gnu99"

Is there something I'm missing when attempting to run an iOS application?

Cheers

Indigo

[David Santiago]

I reported this bug, which I think might be the same thing I ran into: https://github.com/google/bazel/issues/131. Basically I think you also need the --ios_simulator_version flag, and also a small bug fix. I submitted a patch for it that is under review here: https://bazel-review.googlesource.com/#/c/1150/  It looks like it'll be a while getting that merged into the main repo, so you might make this one-line change yourself in the meantime if you need it. 

Hope that helps. In the meantime, can you share your ios_application usage? I've tried to get ios_application() working, and have mostly failed, so I've fallen back on objc_binary(). It is apparently in the process of getting gutted, but in the meantime it's all I've had success using so far.

[Indigo Orton]

Hi David,

That's exactly what is happening to me. Thanks for the solution!

I have a lot of objc_libraries that compile most of my code (I'm writing an API), then I use an objc_binary for my app (testing app) sources and an ios_application for all app specific resources (e.g. info.plist, bundle id).

Have you found a way of running the app on a device? Or do you just build the application and then install the .ipa manually through xcode/itunes?

Cheers
Indigo

[David Santiago]

On Monday, April 20, 2015 at 4:52:29 PM UTC-7, Indigo Orton wrote:

Hi David,

That's exactly what is happening to me. Thanks for the solution!

I have a lot of objc_libraries that compile most of my code (I'm writing an API), then I use an objc_binary for my app (testing app) sources and an ios_application for all app specific resources (e.g. info.plist, bundle id).

Have you found a way of running the app on a device? Or do you just build the application and then install the .ipa manually through xcode/itunes?

Actually, I only just this past weekend dug through enough of the bazel source code to realize that I've probably been trying to do things wrong. It hadn't occurred to me to run an app on a device in any way other than through generating and xcodeproj and then running it through Xcode. I've been getting build failures in Xcode whenever I try to do that, even if it's already been built by Bazel. The xcodeproj files generated by Bazel don't seem to be complete enough to run an equivalent build, but Xcode doesn't seem to agree that things are up to date if they are built by Xcode. I'm absolutely sure there's something I'm still missing here.

I do notice, though, that the ios_runner.sh script does not appear to have anything that attempts to run an app in any way other than through the simulator: https://github.com/google/bazel/blob/master/tools/objc/ios_runner.sh.mac_template

[Indigo Orton]

If you can't use Xcode with a device how do you debug? Simulator only goes so far (and is restrictive, for example my API uses the camera, which the simulator does not support).

To the bazel team: When should we expect support for these issues (xcode, debugging, device)? Is there some workflow that you use internally that works well with Bazel for developing iOS?

Thanks in advance

Indigo

[Ulf Adams]

Sorry, we're a bit overloaded with ios requests right now. There are still some pieces missing from bazel, in particular test support (which will hopefully also support running the test on a device).

From memory, I think we're building an ipk; can that be uploaded to a device?

Wrt. xcode project generation, can you be more specific as to what is missing?

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To post to this group, send email to bazel-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/8133649a-6a20-424a-8b5b-30a487e48145%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[David Santiago]

On Tuesday, April 21, 2015 at 9:52:06 AM UTC-7, Ulf Adams wrote:

Sorry, we're a bit overloaded with ios requests right now. There are still some pieces missing from bazel, in particular test support (which will hopefully also support running the test on a device).

From memory, I think we're building an ipk; can that be uploaded to a device?

Wrt. xcode project generation, can you be more specific as to what is missing?

Sorry for any contribution to the overload, not intended! I noticed that this commit (https://github.com/google/bazel/commit/44d00bfb252abb32f8f0c17b642b47a0f99b06b1) appears to have resolved my ios_application() issue. It does now build and run successfully in Xcode, and I can run my app on my iOS devices using Xcode. I will look into the .ipa files and see if there is a way to make Xcode run the ones built by Bazel on the device. I've only ever run projects I build through Xcode.

But maybe nothing is missing from the xcodeproj generation. It depends on what the intended workflow is for using Bazel for iOS. Some essential aspects of Xcode seem difficult and unnecessary to replace, so it's a matter of where the lines are drawn between Bazel and Xcode. It could well be that the fix for our issues here is a few paragraph long blog post or documentation page about how to accomplish the key tasks in building an iOS app using Bazel. As it is now, I think it's easy for people to see an xcodeproj get spit out after a bazel build and think that the project should be buildable in Xcode, when it might be the case that this is not what was intended, and the xcodeproj is there for working with xibs and core data models and other things like that. 

So that said, I posted (https://groups.google.com/forum/#!topic/bazel-dev/m4zdsR_PcEM), which reports that the xcodeproj generated for Bazel's example iOS application will fail to copy the compiled CoreData models into the application bundle when built via Xcode, causing a runtime failure at launch. The file runs correctly when built and run through Bazel. It appears that Bazel uses its own method of compiling/bundling the coredata models, and does not leave any build instructions for how to do that in the generated xcodeproj. Again, possibly working as intended, but could be confusing to users who attempt to build the example project through Xcode.

Along similar lines, I have a small worry about the plist files. Bazel appears to have its own tool to merge together plist files, so it does this during the bazel build and then generates an xcodeproj that points at the bazel-merged plist file. This is not a file the user can see in their source directory, but it does appear in Xcode as a "source" file, when really it's an output. Meanwhile the actual input plists don't appear in the Xcode project. Xcode will let them edit the merged file, which I imagine will work until they do a bazel rebuild and lose their changes. It seems like docs should mention this, at least. Perhaps someday bazel could generate custom rules in the xcodeproj to run the plist merge in the same way as it would on the command line, but that would be a lot more work, I imagine. The plist editing interface in Xcode is nice to use, though.

[Ulf Adams]

On Tue, Apr 21, 2015 at 9:30 PM, David Santiago <david.s...@gmail.com> wrote:

On Tuesday, April 21, 2015 at 9:52:06 AM UTC-7, Ulf Adams wrote:

Sorry, we're a bit overloaded with ios requests right now. There are still some pieces missing from bazel, in particular test support (which will hopefully also support running the test on a device).

From memory, I think we're building an ipk; can that be uploaded to a device?

Wrt. xcode project generation, can you be more specific as to what is missing?

Sorry for any contribution to the overload, not intended! I noticed that this commit (https://github.com/google/bazel/commit/44d00bfb252abb32f8f0c17b642b47a0f99b06b1) appears to have resolved my ios_application() issue. It does now build and run successfully in Xcode, and I can run my app on my iOS devices using Xcode. I will look into the .ipa files and see if there is a way to make Xcode run the ones built by Bazel on the device. I've only ever run projects I build through Xcode.

All feedback is appreciated, but requests for features and bug reports may take a while to process.

 

But maybe nothing is missing from the xcodeproj generation. It depends on what the intended workflow is for using Bazel for iOS. Some essential aspects of Xcode seem difficult and unnecessary to replace, so it's a matter of where the lines are drawn between Bazel and Xcode. It could well be that the fix for our issues here is a few paragraph long blog post or documentation page about how to accomplish the key tasks in building an iOS app using Bazel. As it is now, I think it's easy for people to see an xcodeproj get spit out after a bazel build and think that the project should be buildable in Xcode, when it might be the case that this is not what was intended, and the xcodeproj is there for working with xibs and core data models and other things like that. 

I believe the xcodeproj file is intended to work.

 

So that said, I posted (https://groups.google.com/forum/#!topic/bazel-dev/m4zdsR_PcEM), which reports that the xcodeproj generated for Bazel's example iOS application will fail to copy the compiled CoreData models into the application bundle when built via Xcode, causing a runtime failure at launch. The file runs correctly when built and run through Bazel. It appears that Bazel uses its own method of compiling/bundling the coredata models, and does not leave any build instructions for how to do that in the generated xcodeproj. Again, possibly working as intended, but could be confusing to users who attempt to build the example project through Xcode.

I'm pretty sure that's not WAI.

 

Along similar lines, I have a small worry about the plist files. Bazel appears to have its own tool to merge together plist files, so it does this during the bazel build and then generates an xcodeproj that points at the bazel-merged plist file. This is not a file the user can see in their source directory, but it does appear in Xcode as a "source" file, when really it's an output. Meanwhile the actual input plists don't appear in the Xcode project. Xcode will let them edit the merged file, which I imagine will work until they do a bazel rebuild and lose their changes. It seems like docs should mention this, at least. Perhaps someday bazel could generate custom rules in the xcodeproj to run the plist merge in the same way as it would on the command line, but that would be a lot more work, I imagine. The plist editing interface in Xcode is nice to use, though.

We chmod all output files read-only (I think). If you work with bazel a lot, you quickly learn that files under bazel-out aren't intended for editing. But I guess we could be more explicit about that in the docs.

 

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To post to this group, send email to bazel-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/4cd7f61f-988e-48cf-ae33-77506df4ddeb%40googlegroups.com.

[Peter Schmitt]

Hi David,

thanks a lot for your thoughtful feedback! The eventual goal is definitely for the Bazel-generated Xcode projects to be buildable, anything else is a bug. With the introduction of ios_application (which happened very recently) we've fallen behind a bit and its support in particular for the project generation is broken in several places. We're slowly addressing that and any assistance is welcome! :)

With regards to custom tools employed by blaze during its build of an IPA for steps normally performed by Xcode, those should reflect the same work done by Xcode. In most cases (e.g. actool or ibtool) we call a thin wrapper around an existing tool that is also called by Xcode. 

The plist is an interesting and tricky case, but I agree that eventually the individual pieces should be editable in the project, not the merged one. The reason why the merged one may be necessary right now is that Blaze performs some variable substitutions on it which would need to be replicated as a custom step in Xcode.

Oh, and that the example project doesn't build in Xcode is a bug, we'll have to look into that. It should work (and I thought I'd seen it work) so not sure what's going wrong.

Peter

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To post to this group, send email to bazel-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/4cd7f61f-988e-48cf-ae33-77506df4ddeb%40googlegroups.com.

[David Santiago]

On Tuesday, April 21, 2015 at 12:37:25 PM UTC-7, Ulf Adams wrote:

So that said, I posted (https://groups.google.com/forum/#!topic/bazel-dev/m4zdsR_PcEM), which reports that the xcodeproj generated for Bazel's example iOS application will fail to copy the compiled CoreData models into the application bundle when built via Xcode, causing a runtime failure at launch. The file runs correctly when built and run through Bazel. It appears that Bazel uses its own method of compiling/bundling the coredata models, and does not leave any build instructions for how to do that in the generated xcodeproj. Again, possibly working as intended, but could be confusing to users who attempt to build the example project through Xcode.

I'm pretty sure that's not WAI.

OK, CoreData is not a key feature for me, I was just trying to improve the new-user experience for ios projects. How about I just file an issue for this on github and we'll get to it later, unless someone else is having CoreData issues.

 

Along similar lines, I have a small worry about the plist files. Bazel appears to have its own tool to merge together plist files, so it does this during the bazel build and then generates an xcodeproj that points at the bazel-merged plist file. This is not a file the user can see in their source directory, but it does appear in Xcode as a "source" file, when really it's an output. Meanwhile the actual input plists don't appear in the Xcode project. Xcode will let them edit the merged file, which I imagine will work until they do a bazel rebuild and lose their changes. It seems like docs should mention this, at least. Perhaps someday bazel could generate custom rules in the xcodeproj to run the plist merge in the same way as it would on the command line, but that would be a lot more work, I imagine. The plist editing interface in Xcode is nice to use, though.

We chmod all output files read-only (I think). If you work with bazel a lot, you quickly learn that files under bazel-out aren't intended for editing. But I guess we could be more explicit about that in the docs.

Indeed, I did see that. But Xcode helpfully pops a dialog offering to fix this for you, which might be tempting for users who haven't received an orientation in Bazel. 

[David Santiago]

On Tuesday, April 21, 2015 at 12:51:35 PM UTC-7, schmitt wrote:

Hi David,

thanks a lot for your thoughtful feedback! The eventual goal is definitely for the Bazel-generated Xcode projects to be buildable, anything else is a bug. With the introduction of ios_application (which happened very recently) we've fallen behind a bit and its support in particular for the project generation is broken in several places. We're slowly addressing that and any assistance is welcome! :)

With regards to custom tools employed by blaze during its build of an IPA for steps normally performed by Xcode, those should reflect the same work done by Xcode. In most cases (e.g. actool or ibtool) we call a thin wrapper around an existing tool that is also called by Xcode. 

The plist is an interesting and tricky case, but I agree that eventually the individual pieces should be editable in the project, not the merged one. The reason why the merged one may be necessary right now is that Blaze performs some variable substitutions on it which would need to be replicated as a custom step in Xcode.

Oh, and that the example project doesn't build in Xcode is a bug, we'll have to look into that. It should work (and I thought I'd seen it work) so not sure what's going wrong.

 OK, thanks for the explanation of what's going on, it's helpful to now have an idea of what I should be seeing in this part of the project. 

One small clarification, regarding your last paragraph: You probably did see it build, because Xcode will report a successful build. The issue is that it terminates due to a failed assertion when you run it (after Xcode builds it). I was speaking loosely about it not "building" correctly, because the assertion is caused by the absence of a file that should be in the bundle at runtime.

[Indigo Orton]

David, have you run into a bundling error when running in a simulator? I have my Main.storyboard included in the objc_binary (note: I have fallen back to using that, as you said), however, when I run the app it breaks saying "Could not find a storyboard named 'Main' in bundle NSBundle".

[David Santiago]

On Wednesday, April 22, 2015 at 11:04:00 AM UTC-7, Indigo Orton wrote:

David, have you run into a bundling error when running in a simulator? I have my Main.storyboard included in the objc_binary (note: I have fallen back to using that, as you said), however, when I run the app it breaks saying "Could not find a storyboard named 'Main' in bundle NSBundle".

I hadn't tried this before, but I do see this same thing when I try to build and run an app with a storyboard in it. I spent a little time trying to track this down today. It appears to me like the build step responsible for compiling the .storyboard into a .storyboardc has some sort of error in it that results in an empty directory being created. As far as I can tell, the storyboard is compiled by a target like this (debugging printlns inserted by me, long and seemingly irrelevant parts removed by me, poor choice of test project name (Storyboard) also my fault): 

David-Santiagos-Computer:Storyboard David$ bazel build ios_client/Storyboard --ios_sdk_version=8.3 --subcommands

Artifact storyboard: Artifact:[/Users/David/Desktop/Storyboard[source]]ios_client/resources/Main.storyboard

intermediateArtifacts.compiledStoryboardZip: Artifact:[[/private/var/tmp/_bazel_David/c52cf19ab369f7ec1fe0b85b512a5c2b/Storyboard]bazel-out/local_darwin-fastbuild/bin]ios_client/StoryboardBinary/Main.storyboard.zip

Artifact storyboard: Artifact:[/Users/David/Desktop/Storyboard[source]]ios_client/resources/Main.storyboard

intermediateArtifacts.compiledStoryboardZip: Artifact:[[/private/var/tmp/_bazel_David/c52cf19ab369f7ec1fe0b85b512a5c2b/Storyboard]bazel-out/local_darwin-fastbuild/bin]ios_client/Storyboard/Main.storyboard.zip

INFO: Found 1 target...

     [[... much output removed by me ...]]

>>>>> # //ios_client:Storyboard

(cd /private/var/tmp/_bazel_David/c52cf19ab369f7ec1fe0b85b512a5c2b/Storyboard && \

  exec env - \

  /usr/bin/java -jar bazel-out/host/bin/tools/objc/ibtoolzip_deploy.jar bazel-out/local_darwin-fastbuild/bin/ios_client/Storyboard/Main.storyboard.zip Main.storyboardc /Applications/Xcode.app/Contents/Developer/usr/bin/ibtool --minimum-deployment-target 7.0 ios_client/resources/Main.storyboard)

INFO: From StoryboardCompile ios_client/Storyboard/Main.storyboard.zip:

[/Applications/Xcode.app/Contents/Developer/usr/bin/ibtool, --compile, /tmp/ZippingOutput3314763693925859654/Main.storyboardc, --minimum-deployment-target, 7.0, ios_client/resources/Main.storyboard]

INFO: From XibCompile ios_client/resources/Interface.nib.zip:

[/Applications/Xcode.app/Contents/Developer/usr/bin/ibtool, --compile, /tmp/ZippingOutput9085167692119432322/Interface.nib, --minimum-deployment-target, 7.0, ios_client/resources/Interface.xib]

>>>>> # //ios_client:Storyboard

(cd /private/var/tmp/_bazel_David/c52cf19ab369f7ec1fe0b85b512a5c2b/Storyboard && \

  exec env - \

  bazel-out/host/bin/tools/objc/bundlemerge bazel-out/local_darwin-fastbuild/bin/ios_client/Storyboard.ipa-control)

Target //ios_client:Storyboard up-to-date:

  bazel-bin/ios_client/Storyboard.ipa

  bazel-bin/ios_client/Storyboard.xcodeproj/project.pbxproj

INFO: Elapsed time: 2.935s, Critical Path: 2.29s

When I run the command that it executes for that build step by hand, it only generates an empty directory called Main.storyboardc. The resulting zip file Main.storyboard.zip is 22 bytes and has nothing in it. At runtime, it terminates with the same complaint you posted. 

It appears that the same command line options are used to compile storyboards and xibs, though the xibs do successfully compile into nibs that appear in the app bundle. I'm not sure what's going on here, but it appears that something is going wrong with ibtool that is resulting in it not outputting the necessary files, so they don't make it into the bundle. I couldn't find any docs on how exactly to use ibtool to compile .storyboard files, so I'm not sure where this is going wrong exactly. Do you have any more knowledge of how this should work?

[David Santiago]

I found a little more time to look at this tonight. I think I've found the problem: the ibtool command needs different arguments to compile the storyboard correctly. 

Currently, the ibtoolzip command hardcodes a particular command that works for compiling .xib files: https://github.com/google/bazel/blob/master/src/tools/xcode-common/java/com/google/devtools/build/xcode/ibtoolzip/IbtoolZip.java#L44 In order to compile a storyboard, the --compile option can't be given, since the output is a number of directories. A command that WILL successfully build a storyboard would be the following: 

/Applications/Xcode.app/Contents/Developer/usr/bin/ibtool --target-device iphone --target-device ipad --minimum-deployment-target 7.0 --compilation-directory . ios_client/resources/Main.storyboard

The --target-device options would correspond to the "families" key on the ios_application() rule. The --compilation-directory would be the temp directory that ibtoolzip_deploy has created.

But I'm not sure it's possible to make this change without some more involved changes to these interfaces. One thing that I think would work would be to modify ibtoolzip so that it accepts arguments that tell it what kind of ibtool command it should prepare: for a xib or a storyboard. Another option might be creating another tool parallel to ibtoolzip, say sbtoolzip, that works very similarly but is intended for storyboards. Probably other things would work as well. I'd be happy to work on a patch for this, if that's not going to mess with your internal backlog etc, but I'd need some direction on how to approach this issue. 

[Peter Schmitt]

Thanks for looking further into this! A fix would be much appreciated.

It is unfortunate that ibtoolzip hardcodes the --compile flag. I'd like to avoid adding another tool though, maybe we can pass a new parameter that indicates whether to compile from a file or directory? 

Families are a little trickier, they're currently defined on release bundles only, whereas storyboards can be defined anywhere and are compiled as part of any bundle. Since it's possible to build a bundle directly (using Blaze), we can't rely on the information coming from the app or extension and so need to move the families attribute to bundles in general. Then we should be able to easily pass it to the ibtool invocation.  

--

You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To post to this group, send email to bazel-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/9ae43cb6-a4e3-4568-a224-56a68c7281b6%40googlegroups.com.

[David Santiago]

On Thursday, April 23, 2015 at 1:41:28 PM UTC-7, schmitt wrote:

Thanks for looking further into this! A fix would be much appreciated.

I'll start working on one. 

 

It is unfortunate that ibtoolzip hardcodes the --compile flag. I'd like to avoid adding another tool though, maybe we can pass a new parameter that indicates whether to compile from a file or directory? 

Actually, this is not necessary. I confused myself when trying to reverse engineer the minimal set of options needed to get a successful storyboard compile out of ibtool. The --compile flag is actually fine. If build equivalence between Xcode and Bazel is desired, however, it's worth figuring out what those other flags do and whether Bazel should be doing them by default. Or perhaps providing options to control them. For the record, here's what Xcode does by default to build a storyboard:

/Applications/Xcode.app/Contents/Developer/usr/bin/ibtool --target-device iphone --errors --warnings --notices --module Storyboard --minimum-deployment-target 7.0 --output-partial-info-plist /var/tmp/_bazel_David/c52cf19ab369f7ec1fe0b85b512a5c2b/Storyboard/bazel-out/local_darwin-fastbuild/bin/ios_client/build/Storyboard.build/Debug-iphoneos/Storyboard_ios_client.build/Main-SBPartialInfo.plist --auto-activate-custom-fonts --output-format human-readable-text --compilation-directory /var/tmp/_bazel_David/c52cf19ab369f7ec1fe0b85b512a5c2b/Storyboard/bazel-out/local_darwin-fastbuild/bin/ios_client/build/Debug-iphoneos/Storyboard.app /var/tmp/_bazel_David/c52cf19ab369f7ec1fe0b85b512a5c2b/Storyboard/ios_client/resources/Main.storyboard

However, it does appear that the -target-device flags are the essential ingredient to get a non-empty compiled storyboard. Which is kind of a bummer in light of...

 

Families are a little trickier, they're currently defined on release bundles only, whereas storyboards can be defined anywhere and are compiled as part of any bundle. Since it's possible to build a bundle directly (using Blaze), we can't rely on the information coming from the app or extension and so need to move the families attribute to bundles in general. Then we should be able to easily pass it to the ibtool invocation.  

That all makes sense. Should I make a stab at this in my fix?

[Indigo Orton]

Hi everyone,

Just to check up, are we able to run iOS built from Bazel in any way? Or is Bazel not ready for iOS? Is it only storyboard-based apps that break?

Cheers

Indigo

[David Santiago]

I have built iOS apps and run them on devices, but they were built by Xcode from the bazel-generated xcodeproj and had no storyboards. I have not figured out how to build with bazel for a device. I am working on a fix for the storyboard issue along the lines of peter's last mail. 

[Indigo Orton]

Ok, thanks David.

[David Santiago]

Actually, I misspoke. I was remembering the CoreData issue. You should be able to build bazel-generated xcodeprojs with storyboards in Xcode, I think. It's the CoreData files that don't get built by the bazel-generated xcodeproj files.