When I edit my storyboard, then go back to Xamarin Studio to run my app, Xcode quits.
Every time this happens I lose my edit history.
And it happens EVERY time I open Xamarin Studio.
I have the same issue.
The problem is that when you switch back to Xamarin Studio, it deletes the temporary project that it exported to Xcode which causes Xcode to crash (actually current versions tell Xcode to exit cleanly in order to avoid the crash).
I would recommend using Xamarin Studio's built-in iOS UI Designer instead. If that isn't good enough to use, then we'd prefer you tell us what bugs you need fixed in that and/or what features you need so that we can address your needs that way.
We are pushing to completely drop support for exporting to Xcode as it doesn't make sense to support 2 different ways of doing the same thing.
When I try to open the file using the built-in UI Designer it says "This version does not have support for files saved in Xcode 8 format."
"This version does not have support for files saved in Xcode 8 format." is an intentional restriction at the moment. The release notes [1, 2] have now been updated to mention that restriction (also tracked in Bug 44330).
I really disagree with this. I think it makes perfect sense. Personally I really dislike the Xamarin built-in designer. I find the Xcode interface builder much more intuitive to use and especially coming from an iOS background I'd rather work in Xcode where I am familiar with the UI and controls.
I don't think Xamarin should coerce the developer in to using one or the other. I think that would be a big step backwards. Someone who's in charge of this whole 'pushing to drop support' strategy, really needs to have a rethink. I fail to see the limitations of supporting Xcode.
I might be mistaken in my interpretation of Jeff's Comment 3, but it sounds like something changed in Xcode 8 that makes it _technically_ untenable to leave the generated Xcode project open when moving back and forth between Xamarin Studio and Xcode. It sounds like using the same old approach used for Xcode 7 would cause Xcode 8 to _crash_.
Indeed, in my tests this restriction appears _not_ to apply to Xcode 7: Xcode 7 remains open when I switch back to Xamarin Studio.
Providing support for not quitting Xcode 8 between synchronizations might therefore rise to the level of a "feature request" of sorts, so the best way to pursue that request might in the end be to submit a request for it on https://xamarin.uservoice.com/ (something along the lines of "Do not require Xcode 8 to quit when synchronizing changes into Xamarin Studio"). As a caution, I myself don't know enough about the technical limitations to know if the feature is feasible, but if nothing else, the UserVoice post would provide a place to tally up votes for the request to assess user demand relative to other features.
*** Bug 44489 has been marked as a duplicate of this bug. ***
The Xcode sync has always been very problematic. Apple does not allow third parties to extend Xcode, and the only way we have to interop with it via modifying files directly and hoping it picks up the changes correctly (which isn't always true, and has causes it to crash), and sending it commands via AppleScript (which is very race-prone).
Fundamentally, Xcode makes it near-impossible to do this synchronization _well_.
To clarify - we are not dropping Xcode support at the moment. We would _like_ to be able to drop Xcode support, because Xcode does not allow us to make it work reliably, however we recognize that there is still a need to use it sometimes.
Please Xamarin DO NOT remove support for opening Xcode. The built in IOS designer is too slow. Not at all intuitive to use (Auto layout especially) I've been using Auto layout for years, been through the University course for the IOS Designer and I still don't 'get' the designer's approach to it.
Also, there have been times when the designer did not offer the same features as Xcode for a long time (Template Image assets as an example)
So if Xcode introduces a really cool feature, we will not be able to take advantage of it until Xamarin deem it worthy of adding to their Designer.
Just to add another voice - this is a serious regression for us, although it sounds like there are good technical reasons for it.
My current workaround is to batch up UI changes, then Open in Xcode Interface Builder, and try to get everything done before I switch back to Xamarin Studio. If I forget something, then I have to go through the process again (and it's not quick, with upwards of 60 view controllers to load in Xcode).
I've tried hard in the past to use Xamarin Studio's interface designer, but as mentioned above, there are just too many shortcomings. Originally, I didn't use it because it didn't support multiple left / right button items on a navigation bar. This has been fixed now, but I still find the auto layout editor confusing / impossible to use for more advanced constraints, and editing static table cells with custom views has never worked properly for me. It's also quite slow compared to Xcode's designer (at least for the aforementioned storyboard, with dozens of scenes, and yes, I could split them up into multiple storyboards, but up till now Xcode's designer has been working well for me).
Anyway, I do understand that it's challenging to get Xcode integration working well. Just wanted to make sure Xamarin knows that there are still good reasons for needing it.
Dropping Xcode support should not be an option right now. The iOS designer is (and always was) inferior to Xcode! It is much much slower (our storyboard didn't load up after 5 minutes, at that point I gave up trying). About a year ago Xamarin even recommended using Xcode instead because they knew the iOS designer doesn't work flawless.
With respect, I would drop support for the IOS Designer and concentrate on Xcode support.
To reiterate Comment 10, there is _no_ current plan to drop support for Xcode synchronization any time soon.
The issue currently under question is whether it is technically feasible to enhance the Xcode synchronization support for Xcode 8 such that it is not necessary for Xamarin Studio to close Xcode 8 when performing the synchronization. As Mikayla elaborated in Comment 9, Xcode does not make this easy due to the limited extensibility it provides, so it is not clear (at least to me) at this time how much can be done to mitigate that behavior.
However, users who are interested discussing the subtleties about that synchronization limitation are invited to vote or contribute creative or constructive ideas on the corresponding UserVoice item that Mark has kindly posted:
*** Bug 44574 has been marked as a duplicate of this bug. ***
Sorry but I think this is a big mistake. The XCode support is mandatory until you don't give to developers a real alternative to it. Your iOs designer is slow and very difficult to use for a lot of reasons. This is a big regression and not only for Xamarin.iOs devs.
Why not have a look at the way Unity the game engine handles xcode projects.
We don't use the Xamarin Studio designer because we prefer native iOS tools and the always up to date xcode storyboard capabilities that are far far far superior to the xamarin studio designer chase. Do what it takes to make this work, I have NEVER had an issue with xcode syncing changes to xamarin studio. This is very disruptive and sadly finding this out after public releases / stable channel.
Fixed in version 18.104.22.1687 (master)
Author: Jeffrey Stedfast
Commit: 882fd46329ad18d1ae69619ab0ab7692fd2826cf (xamarin/md-addins)
Included in Commit: 2d5a2468e0a7bfd4f8a914042e65b21c440860ef (mono/monodevelop)
When the fix will be available on Stable/Beta channel?
Personally I think this should be an emergency patch release. This issue is causing significant productivity delays.
*** Bug 44717 has been marked as a duplicate of this bug. ***
Updating target milestone to 6.2.0 (C9) for verification based on commit location in Comment 20.
As Xcode is not crashing when user try to sync with XS as shown in screencast : http://www.screencast.com/t/5hs0kAE5
Now we are getting different issue and for this an issue is already filed i.e. https://bugzilla.xamarin.com/show_bug.cgi?id=36623
Hence closing this issue as original issue mentioned in but description is fixed.
=== Xamarin Studio Enterprise ===
Version 6.2 (build 619)
Installation UUID: fd96f29c-8917-44db-ad82-5331551e9d03
Mono 4.9.0 (master/8994ce8) (64-bit)
GTK+ 2.24.23 (Raleigh theme)
Package version: 409000187
=== NuGet ===
=== Xamarin.Profiler ===
=== Apple Developer Tools ===
Xcode 8.0 (11246)
=== Xamarin.iOS ===
Version: 10.1.0.82 (Xamarin Enterprise)
Build date: 2016-09-26 13:32:23-0400
=== Xamarin.Android ===
Version: 22.214.171.124 (Xamarin Enterprise)
Android SDK: /Users/xamarin77/Desktop/android-sdk-macosx_êèéæâàçéè€ÿëïœ_a
Supported Android versions:
2.3 (API level 10)
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
4.4.87 (API level 20)
5.0 (API level 21)
5.1 (API level 22)
6.0 (API level 23)
SDK Tools Version: 25.1.7
SDK Platform Tools Version: 24.0.2
SDK Build Tools Version: 24.0.2
Java SDK: /usr
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
Android Designer EPL code available here:
=== Xamarin Android Player ===
Location: /Applications/Xamarin Android Player.app
=== Xamarin.Mac ===
Version: 126.96.36.199 (Xamarin Enterprise)
=== Build Information ===
Release ID: 602000619
Git revision: a0b27d3c20fdf91a895dd7bb8c7afa0819d3624a
Build date: 2016-09-27 06:35:35-04
Xamarin addins: 83f6112121f19b3a65763c7c4db9a1e0703c4d31
Build lane: monodevelop-lion-master
=== Operating System ===
Mac OS X 10.11.5
Darwin Xamarin77Macmini.local 15.5.0 Darwin Kernel Version 15.5.0
Tue Apr 19 18:36:36 PDT 2016
=== Enabled user installed addins ===
Gist Ide Information 1.0.2
Addin Maker 1.3.2
NuGet Package Management Extensions 0.11.1
I'm going to reopen this bug, because I don't think the user complaints are completely addressed. Sure, Xcode no longer quits, but the temporary workspace is still deleted. Therefore, when the user goes to edit the storyboard in Xcode Interface Builder again (launching from XS context menu), a new project is created/opened in Xcode and hence the storyboards all need to be loaded up again and the user's edit history is still lost, which I believe to be the main complaints in this bug report.
In addition, when switching back to XS, the user is presented with dialogs from Xcode complaining about the missing temporary workspace. So, the user experience here is slightly worse, in my opinion.
I understand we might not have the technical ability to properly fix this issue, but I don't believe the current patch is enough to consider this bug resolved.
I'm experiencing this same problem but PLEASE DO NOT DROP XCODE SUPPORT!
Xamarin's Studio IB is completely useless! It's takes forever to open a file and the representation of the UI is almost always wrong for any moderately-complex Xib file! You guys didn't even support StackViews until last week! I can't imagine how anyone even uses Xamarin's IB.
This would seriously be a deal-breaker for us. If we can't use Xcode's IB then we wouldn't be able to continue using Xamarin because your IB is worthless to us.
Kyle: we can't "fix" that because there may be stale files in the temp project and if we don't clean it up, then we may end up re-importing something that a user has deleted inside Xamarin Studio.
It's why we currently delete the temp project after we sync stuff back from Xcode.
This is the way things have always worked.
This bug report is about Xamarin Studio forcing Xcode to exit when syncing the temp project back into Xamarin Studio and that has been fixed in the current alpha 6.2.0 builds.
I get that it's not easy to fix the problem but I don't really agree that not quiting xcode but still losing your edit history solves this bug.
The bug report I filed said:
When I edit my storyboard, then go back to Xamarin Studio to run my app, Xcode quits.
Every time this happens I lose my edit history.
And it happens EVERY time I open Xamarin Studio.
Losing the work you just did, every time you switch to XS makes it so much harder to work, so that is the main issue here
*** Bug 44891 has been marked as a duplicate of this bug. ***
Everyone seems to be confused about what has changed recently that caused this bug. The fact is that the change to kill Xcode was made in 2014. The reason people are now seeing this is that killing Xcode has always been a *fallback* for cases where Xcode failed to respond via our AppleScript commands. What this means is that Xcode is just more prone to not responding now than it has been in the past.
I've removed the fallback in the hopes that Xcode is fulfilling our requests and just not replying back to us via AppleScript.
Beyond that, there is nothing we can do.
What if we just had a Xamarin Studio menu command "Open Project in Xcode"? Then I could go there and do all of my IB work and when done either Xamarin Studio detects changes and offers to "reload project" or I have to manually close and reopen my solution. I have never had a problem with using xcode but if I could just at least get TO xcode to do my work so I can use the designer I know and love (and trust) then that's a compromise as well.
I was actually going to say that the only way to improve this at all would be to leave it to the user to specify when to export to Xcode and when to import back the changes because it's the logic that tries to automatically synchronize things with Xcode that heavily relies on AppleScript. Without the need for AppleScript, things could be left to the user to manually tell XS when to do things thus bypassing the need to ever close Xcode or the Xcode project because it would all be the user's responsibility.
I didn't think anyone would go for that so I didn't mention it.
But if people would be ok with that, then I could probably be persuaded to implement menu items for that and remove the logic that tries to automatically do this stuff.
I just want to use IB, whatever it takes is fine with me. Just like when we switched to archive, it's a change but once we learn it's fine. Educate, document, whatever. But let me keep using xcode IB please. Thank you.
We've already got open in Xcode. One more menu item to resync wouldn't be a problem. It's just a case of getting used to using. It would be like a when out of habit I would perform a clean and rebuild to force a sync when it used to not work properly
Is the issue not being able to reliably detect when the storyboard file changes in Xcode? FYI, you can use grand central dispatch to detect file system changes. There are a couple good blog posts about it here:
No, it's not about detecting file system changes, it's more about syncing changes to/from Xcode w/o race conditions.
I would definitely be fine with a manual option to sync the changes to/from Xcode! All I care about is being able to continue using IB without having to reopen Xcode every time I want to test a change.
I would propose doing something that SourceTree does when merging files. They require the user to quit the merge application to sync the changes.
Similarly, when you open a XIB in Xcode, XS can automatically show an empty tab with a "sync changes" button. This way it's obvious another action needs to take. I can't imagine this user experience will be problematic for anyone and is infinitely better than the alternatives.
The original commit was reverted so I'll reopen this to continue tracking.
Fixed in version 188.8.131.527 (master)
Author: Jeffrey Stedfast
Commit: fa0b75459575ea6f7f54d1276206bbbdfe0ff11d (xamarin/md-addins)
Included in Commit: 67034cce071b21a882cf58e0aa88c3ef3cafcf8d (mono/monodevelop)
After Brendan discovered that if his project was located in his home directory, Xcode 7.3 would remain open when he switched back to XS *but* if he did the exact same thing with a project located in /private/tmp, it would kill Xcode, we thought that maybe the issue was that Xcode and XS were referring to the same project path in a different ways (i.e. maybe XS and Xcode were inconsistently resolving symlinks, etc).
I updated XS's AppleScript commands to use "real path of ..." and also updated XS to make sure that the paths it fed into the AppleScript commands were also resolved to real paths, I went to test things out with Xcode8 on my local machine and still failed.
So I opened up the AppleScript Editor app and c&p'd the failing AppleScript script into the editor and low-and-behold, for Xcode8, AppleScript *always* responds that Xcode8 is NOT RUNNING even when it is.
Tried the same exact script with Xcode 6.4 (I tried 7.3 but my 7.3 keeps crashing, I think it conflicts with 8 somehow?) and low-and-behold, Xcode 6.4 properly reports itself as running.
Basically, it means that *none* of our AppleScript scripts work anymore with Xcode8 :(
tell application "/Applications/Xcode.app"
if it is running then
with timeout of 30 seconds
set projectPath to "/Users/fejj/Projects/XcodeSyncTest/XcodeSyncTest/obj/Xcode/0/XcodeSyncTest.xcodeproj"
repeat with proj in projects
if real path of proj is projectPath then
return "WHY HATH THOU FORSAKEN ME!?!?"
This is roughly what our script looks like to check if Xcode has our exported project opened.
For Xcode 8, this always returns "WHY HATH THOU FORSAKEN ME!?!?". With Xcode6.4, it returns "true"
This means that the "if it is running" phrase always evaluates to false for Xcode8 but for Xcode 6.4, it evaluates to the correct value (i.e. true if it is actually running).
What happens is that when you switch back from Xcode8 to XS, XS checks attempts to check if the project is open so it knows whether or not it is safe to delete the exported project. If it is reported as being open by Xcode, then we leave the files alone, but if the script returns false, then we delete the temporary exported Xcode project (as it should be safe to do so).
This is why if we don't `killall -9 Xcode`, it will blow up in your face with tons of error dialogs due to files being removed when Xcode still had them open, so to prevent that I added logic to kill Xcode.
You might say, "Aha! What if you don't killall -9 Xcode *and* you just always leave the exported Xcode project alone?"
Well, then we have the problem if a growing mass of temporary project exports which will grow unbounded. That *also* doesn't solve the problem of not losing the edit history in Xcode because XS *has to assume* that it will have to export to a new temp project because it can't go rewriting files out from under Xcode either.
FWIW, it actually gets worse because I thought, "hmmm, what if we just drop the whole 'if it is running then' bit and just send the inner block of that?" Unfortunately, Xcode no longer seems to actually implement the 'projects' property (it blows up in my face in the AppleScript Editor when I tried to run it).
God knows what else they removed...
So I think at this point, whatever solution we come up with will have to do without the use of AppleScript :(
As a small update on Comment 42 - Comment 45, the Xamarin team will be testing out the `workspace documents` AppleScript property as a potential alternative to the old `projects` property.
Looks like `workspace documents` can work as an alternative so I've modified the code to walk over those documents instead of iterating over the projects. WIth some slight modifications, this seems to work.
I also had to get rid of the "if it is running" bit as that no longer works. I've instead replaced that with a manual query of the running system processes to check if Xcode is running before running the script. So there's a race there now... but it's probably not a major concern and it's the best we can do.
Created attachment 18034 [details]
Detailed version info
## Verification status: partially verified for the core issue from Comment 0, but there is one remaining follow-up issue to examine in Bug 45389
## Extended verification test steps
1. Create a new "iOS > App > Single View App", iPhone project in the user home folder.
2. Select "Open With > Xcode Interface Builder" from the context menu on "Main.storyboard".
3. If 2 windows open in Xcode, close the non-project window.
4. Navigate to `Main.storyboard` in the Xcode project window.
5. Add a UILabel to the view, and then add an outlet for the label. (In Xcode 8 this will require selecting an "initial device view" and updating the document to Xcode 8's new XML format.)
6. Save the document in Xcode.
7. Bring Xamarin Studio back to the foreground.
8. Check that the outlet for the label has been added into `ViewController.designer.cs`
9. Verify that the Xcode window has retained its undo history.
10. Repeat steps 2-8.
11. Add a new "iOS > View Controller" to the project in Xamarin Studio.
12. Verify that the new view controller now appears in the Xcode project window.
## GOOD results (by step) in Xamarin Studio 184.108.40.206 + Xcode 7.3
7. Xcode stays running, and the Xcode project remains open in Xcode.
8. The outlet has been added to the code behind file as expected.
9. The undo history is available as desired. It is possible to undo the addition of the outlet via "Edit > Undo".
10. Xcode again stays running, and the new outlet is again added as expected.
11. Xcode stays running, but the project automatically closes and reopens so that the newly added view controller will be available in the project.
12. The files for the new view controller appear as expected in Xcode.
## BAD results in Xamarin Studio 220.127.116.11 + Xcode 8.0
7. BAD: Xcode quits.
9. Not applicable. (The result of this step only applies if Xcode successfully stays running in step 7.)
10. BAD: Xcode quits (but the new outlet is added successfully to the C# code behind file).
11. Not applicable. (The result of this step only applies if Xcode successfully stays running in step 10.)
## BETTER results in Xamarin Studio 18.104.22.168 + Xcode 8.0
11. BAD: Filed as follow-up Bug 45389. Xamarin Studio fails to close the original Xcode project automatically. This causes a second Xcode window to open with the new project and also causes the following error dialog to appear for the original Xcode project window:
> The workspace file that was at
> has disappeared.
> Do you want to re-save the container, or close it?
> [Close] [Re-save]
That said, clicking "Close" is sufficient to continue working as expected in the new project window.
Guys i already post in Xamarin forums about this things to drop XIB is big mistake.
Without try offending you, the UI Designer isn't good right now for working for enterprise / company apps etc..
We use XIB many years, and it is very quick tool SOLID and robust in UI design.
Xamarin's UI Designer is the difference of day with night its very slow, very buggy, not good user experience (with auto layouts constraints, missing a lot of thinks).
This caused me a lot of issues, in a big project with storyboard that has a lot of UI and can even create a control in ViewControllers from XIB.
So i see that this is resolved.
is it somewhere in Alpha Channel that we can test it?
> i already post in Xamarin forums
Have you also checked existing forum threads about the issue (such as http://forums.xamarin.com/discussion/comment/224194/#Comment_224194)?
As mentioned in Comment 10 and Comment 15, this bug is _not_ an indicator of any timeline for dropping support for synchronizing with Xcode Interface Builder. Removal of that feature is _not_ planned for any time soon, and there is a checklist of items Xamarin would need to complete in order to even think about removing it. It just a bit of bad luck that the first reply from Xamarin in Comment 3 mentioned the _theoretical possibility_ of dropping the sync support.
It is important to keep in mind that the conversation on a bug report is always a dynamic story. Comments that were up-to-date earlier in the conversation are not necessarily relevant later in the conversation. Comment 3 is an example. As discussed in the recent comments Comment 45 - Comment 48, candidate fixes have been found to restore the old familiar behavior of Xcode 7.3 in Xcode 8 for this bug.
## Availability of builds
Work is in progress to coordinate a publication of the candidate fixes in Xamarin Studio to the preview release channels. As mentioned in Comment 48 there was a follow-up issue found during verification. That issue now (as of yesterday afternoon) also has a candidate fix.
The first previews of the new builds are tentatively planned to be published to an updater channel next week (the week of October 17).
If you wish, you could try the experimental build used in the tests in Comment 48 plus the candidate fix for follow-up Bug 45389 , but keep in mind that unlike publications to the release channels, that build _has not undergone any general testing_ apart from the specific testing mentioned in Comment 48.
## Verification of the follow-up Bug 45389: now also verified
I am accordingly marking this bug as verified too.
Working on the weekend for you guys,
## Backwards-compatibility verification for older Xcode versions
GOOD on all steps: Xamarin Studio 22.214.171.124 (cdbaa604) + Xcode 8.0
BAD: Xamarin Studio 126.96.36.199 (cdbaa604) + Xcode 7.3
Follow-up Bug 45524 filed: "Xamarin Studio could not communicate with Xcode" error dialog appears after Xcode project opens.
I will set this bug back to resolved/unverified while awaiting the resolution and verification of that new follow-up bug.
Thanks for the work @ALL. It's obvious many/most of us in iOS prefer to work in xcode IB. I have a bugzilla case somewhere and someone even created an add-on to do this...we want to be able to choose the "default" application to open on storyboards. Please add a setting to Xamarin Studio "Open Storyboards with" a) Xamarin Designer b) Xcode. Then we can go forward with just double-clicking to edit and our desired designer opens.
Thank you JEFF and Co.
> Working on the weekend for you guys,
Much appreciated, Brendan.
Fixed in version 188.8.131.52 (cycle8)
Author: Brendan Zagaeski
Commit: b10b2035a4f8a2eae1ad3667043184b40b24058f (xamarin/md-addins)
Included in Commit: 8937e51ff879e4062e660a70d13463510a2664c4 (mono/monodevelop)
## Verification status, including backwards-compatibility for Xcode 7.3: verified
GOOD on all steps: Xamarin Studio 184.108.40.206 (8937e51f) + Xcode 8.0
GOOD on all steps: Xamarin Studio 220.127.116.11 (8937e51f) + Xcode 7.3
## The particular experimental build tested
(CAUTION: Unlike publications to the release channels, this build _has not undergone any general testing_ apart from the specific testing for this bug. Note also this build includes several other candidate changes for unrelated bugs.)