[xcode11-feature] Add support for Catalyst/UIKitForMac

[Uncommon]

Please add support for "Project Catalyst"/UIKitForMac introduced in macOS 10.15.

[ghost]

+1

[dalexsoto]

Hello, thank you for reaching us!

We are currently working on Xcode 11 support, you can follow this issue with our updates in our progress https://github.com/xamarin/xamarin-macios/issues/6206 and also any help is super welcome 😄

[Uncommon]

What kind of help exactly? Is there something I can work on to help this along?

[dalexsoto]

Hello!

I am so glad you asked! Everyone is welcome to join the Xcode 11 party :) I would recommend:

1. Reading our contribution guide https://github.com/xamarin/xamarin-macios/wiki/How-to-Contribute which is a nice read to get a general feel.
2. Read our bindings guide here https://github.com/xamarin/xamarin-macios/wiki/BINDINGS
3. All set and ready to jump in? Go and pick yourself a Xcode 11 framework from this list https://github.com/xamarin/xamarin-macios/wiki/xcode11-Bindings-Status

If you have trouble starting on this you all are very welcome to join our channel where we can help anyone that wants to contribute :)

Hope this helps!

[mrwcjoughin]

Any news on the Catalyst support? This is urgently needed please

[iMonZ]

+1

[rhavlick]

+1

[tvsports86]

+1

[gdignard]

Following up on this. It's over 3 months since the announcement and as I write this we are now only a couple of days from public release of iOS 13 and I still have no answer for my clients who are (reasonably) wanting to know whether I'll be able to deliver to them applications with all features and functions of the new iOS release.

Catalyst is such a huge feature from the iOS side, could someone at Microsoft please at least state for the record whether there is any intention to implement this, or whether Xamarin is now only targeting partial coverage for iOS or whatever has been decided.

Obviously, we'll all have to live with whatever decision has been made, but it would be very helpful to at least be able to base our future development plans accordingly rather than guesswork based on mere "hope" that Xamarin still has its original mandate.

[rolfbjarne]

@gdignard Our intention is to implement this, but unfortunately we've not had enough time to complete the work for the initial public release of iOS 13. Neither am I able to say when it will be implemented, but it's the top request from the new iOS 13 features, so it will be prioritized accordingly.

[gdignard]

@rolfbjarne Thank you for your response; I'm sorry to learn of the troubles with iOS 13, but knowing that Catalyst is actually on the roadmap is reassuring to learn.

[Uncommon]

Any updates on this, now that iOS 13 support is done and the macOS 10.15 GM seed is up?

[rolfbjarne]

@Uncommon I have no further news than in my last comment, our intention is to implement this, but we have no timeline yet.

[royleban]

Speaking for myself, I think an exact 1-for-1 version of what Xcode provides is not necessary. For example, if we had to create a second Mac Solution that included the same projects as the iOS solution, that would not be a problem. What we want is an easy way to bring iPad apps to Mac and that includes apps that do not use Xamarin Forms. Our app, for example, was built before Forms existed, and still does things (e.g., involving flexible complex layouts) that Forms doesn't support. As @gdignard says, a roadmap would be really helpful. Thanks.

[t9mike]

I don't use Forms, just plain Xamarin.iOS and want Catalyst.

[greatvova]

I use both, Xamarin.Forms and Xamarin.iOS. Can't wait to publish my apps to Mac AppStore.

[follesoe]

One piece of input would be to see if this could be implemented iteratively. I see that we get some warnings now on APIs that are not supported on macOS. I assume this is prep-work for Catalyst, or from updated iOS bindings where these warnings are added to the iOS platform for the same reason?

I understand this is a big feature, both for you but also for developers wanting to port their app to macOS. Some guidance from Apple is available already on what you need to do in order to prepare for Catalyst. If you identify Xamarin specific prep work needed or partial tooling (better warnings/guidance/compiler flags) that could be a stepping stone for developers to be prepared when the feature is complete enough to build macOS Catalyst apps.

[mrwcjoughin]

Please we need Catalyst desparetly! Apart from iOS 13 bugs, this should be the top priority! We are all waiting, and this is way more import than XAML hot reload or anything else related!

[sichy]

@rolfbjarne what is needed for the catalyst binding? am happy to do it, as we need it ourselves. Let me know mate.

[cho-trackman]

I want to help as well, but not sure where to start.

[rolfbjarne]

This is a rather complicated task, here's a rough outline of the bare minimum of what needs to happen in order to make something that can be used to create Catalyst apps:

1. Build the mono runtime for the uikitformac platform. I don't know how to do this, the mono runtime people would probably have to be involved somewhat.
2. Build the code in xamarin-macios/runtime for the uikitformac platform (this won't fully work without the previous step - but I have this almost done already, it just needs the previous step completed first)
3. Add support to our msbuild tasks (this should be fairly trivial)
   • Add a new MtouchPlatform value that specifies which platform to target (https://gist.github.com/rolfbjarne/a186c1297108f29b3430f99d441e566b#file-foo-diff-L24)
   • Define both __IOS__ and __UIKITFORMAC__ when building Catalyst apps.
4. Add support to the mtouch tool to build Catalyst apps (this is the most complex task, mtouch is already quite complex, and this will just make it more so).

There are probably other things that must happen before we're able to create a viable Catalyst app as well.

Things that are missing:

• IDE changes to make this a much nicer experience (it should be possible to get something to work without changes to the IDEs, but it would be necessary to edit the csproj in a text editor for instance).
• There are probably several other areas that need to be updated (storyboard compilation, asset catalogs, etc).

[gdignard]

Is there any sense from the mono runtime folks and the mtouch team about if this is on their radar and, if so, whether they have provided any guidance to you about their time horizons for this?

[charlesroddie]

When this is in place, what will be the pros and cons of deploying a Xamarin.Forms app to mac via catalyst vs via Xamarin.Mac? Will Catalyst allow a simple process where there is a single build and it gets released to the store for iPhone/iPad/Mac?

[mandel-macaque]

@gdignard xamarin-macios does take care of mtouch. @rolfbjarne have we talked with the mono team already?

[rolfbjarne]

@rolfbjarne have we talked with the mono team already?

No, I have not.

[tipa]

Did any new info emerge in the meantime that could help in predicting if or when this could be implemented? I wanted to port my Xamarin.iOS apps to MacOS this year and I am unsure if I should build them as MacOS app with AppKit or wait for this feature to be finished...

[gdignard]

Even from the Apple only (non-Xamarin) side of things, it certainly sounds as though Catalyst may have been introduced by Apple in a "not-quite-ready-for-prime-time" state; something perfectly understandable given that there was pretty much guaranteed to be all sorts of issues identified by the development community that were either not foreseen by Apple and/or that they knew would be potential issues but ones they didn't have time to fully address.

This has certainly been the case with other technologies in the past (and I've been an Apple developer since 1987; this is an old, old story). Based on history, I'd guess there are two paths this might take. One is that at WWDC 2020 they'll introduce support that makes it a mature target or they won't talk about it at all. I think that there's a HUGE chance that it's the former; but there is a non-zero possibility that it's the latter.

Given that it is January and given the state of Catalyst as it is today, I would be entirely satisfied if Microsoft -- well ahead of WWDC 2020 -- started putting into place a workable plan to have their resources primed and ready to quickly implement the necessary support for Catalyst if in fact Apple introduces expanded tooling for Catalyst.

Rolf has described above what would currently be necessary to implement that support, and I don't think the delta between the 2019 version and the 2020 version will be that great; just that the 2020 will likely be a more production-ready target than the 2019 version.

Would this be a pragmatic and workable plan? I can't speak for anyone else, but from my own perspective, if Microsoft was ready to move quickly on this out of WWDC I would be satisfied and could definitely work with that.

[andrewleader]

I would use this immediately for my Xamarin non-Forms app (Power Planner), which is available on Android/iOS, and my users want a Mac version but I can't afford building/supporting a separate Mac app!

[praeclarum]

I have been waiting patiently for this feature and am still shocked that work hasn’t even begun.

Yes devs want this feature. It opens a whole new store for us. We can make more money, dramatically reduce our burden, and stay connected with the rest of the Apple development community.

The lack of interest MIcrosoft is showing in supporting Catalyst is making me doubt my decision to use their products. You are actively denying me income. If I was a normal Apple Dev I would have all my apps on Mac now, earning money. But alas, I’m stuck praying MIcrosoft sees the light. How frustrating!

[gdignard]

We've been Xamarin users since the very very early days and I'm personally disappointed with how the last year or two have gone.

I have been waiting patiently for this feature and am still shocked that work hasn’t even begun.

I am too.

Especially since that back when Microsoft acquired Xamarin, it coincided with lots of other really exciting announcements and taken together, there was a huge emphasis on the write once / target anything for an open .NET universe.

You'd think that Catalyst's introduction would have been seen as fantastic news and something that immediately provided a huge assist and something to be supported and nurtured.

I feel that internally, when someone at Microsoft now thinks "Xamarin" they're not thinking at all the same way that Miguel and Nate did years ago but instead are thinking simply "Xamarin.Forms".

Xamarin announcements / posts / videos / Channel9 demos are now pretty much exclusively Xamarin.Forms making it increasingly feel that the iOS / Android stand-alone targets have been relegated a historical support.

At the same time, we see Blazor now experimentally targeting desktop applications (search YouTube for "NDC 2020 blazor" - for a video posted Feb 13 - and jump to around 54 minutes in for a preview of an experimental Blazor/Electron desktop model with a brief discussion of a Blazor running against native desktop OS immediately following that).

I don't know for sure, but if Microsoft sees Xamarin.Forms + Blazor.Everywhere as its future, the ambivalence for Xamarin.iOS generally -- and Xamarin.Catalyst specifically -- perhaps has some explanation, especially since the implementation of the experimental "native desktop Blazor" implementation is credited to the Xamarin team.

The most frustrating aspect of all this, though, has to be the lack of any substantial direction from Microsoft in response to Apple's WWDC 2019 announcements.

Just letting developers dangle on this and forcing us to read tea leaves to plan for our future is by far the most disappointing thing of all. When Apple announced Catalyst I very naively assumed that Xamarin's commitment would naturally -- even enthusiastically -- extend to take advantage of the opportunity Catalyst offered Xamarin developers.

No news / announcements after 8 months is a let-down. Neither "We don't have a plan for this" nor "We have a plan but don't want to share it with our developers" are good looks.

We have a large upcoming project with an associated choice of platform / hires and I'm growing increasingly stressed because I don't even know if Catalyst is the canary in the coal mine and non-XAML Xamarin is a "dead platform walking" or not.

I really hope not. Looking backwards Xamarin has been such a wonderful thing. I just need to be able to look forward, too.

[bruno-garcia]

From my limited knowledge Xamarin.Android seems to be evolving. Support to AndroidX was just released with tools for migrations. Issues raised on GitHub are replied to really quickly and problems did get solved. That's just my recent and limited experience with Xamarin.Android though. I do surely see a lot of material online for Xamarin.Forms though, and new controls features for it so clearly you're right about the focus here but not sure about the "neglecting Xam.Android" part.

[aspnetde]

We have a large upcoming project with an associated choice of platform / hires and I'm growing increasingly stressed because I don't even know if Catalyst is the canary in the coal mine and non-XAML Xamarin is a "dead platform walking" or not.

Same here, or even worse. My team decided just this week to re-build an app we built with XF a couple of years ago with Xamarin.iOS and Xamarin.Android.

I really hope not. Looking backwards Xamarin has been such a wonderful thing. I just need to be able to look forward, too.

Again, same for me. We’ve been happily building „native“ apps with Xamarin for almost eight years now, and we won’t adopt XF any further. I really hope there is no shift in priorities that will make X.iOS and X.Android eventually make second-class citizens. Otherwise we’re out.

[sichy]

I would not worry about Xamarin.IOS/Android support. That is given as direct bindings are needed for anything to build on top.

But no support for Catalyst still is a blow. Nobody can use Forms in properly professional LOB app, Qs from their team about why, just shows how out of touch tat team is. But seems it is the “go to” tech at MS at the moment. I guess we just need to suffer through another year or two of “get started with Forms” until MS find themselves.

[Mogikan]

Seems like I'm not the only frustrated developer. We need to publish xamarin.iOS app to the Mac app store. No xamarin forms. I hope MS will raise attention to this feature. Being 3 month late this feature needs no more news, but exact timeline. Frustration is increasing and you can ignore all the comments and gain bad reputation.

[bmacombe]

I would not worry about Xamarin.IOS/Android support. That is given as direct bindings are needed for anything to build on top.

But no support for Catalyst still is a blow. Nobody can use Forms in properly professional LOB app, Qs from their team about why, just shows how out of touch tat team is. But seems it is the “go to” tech at MS at the moment. I guess we just need to suffer through another year or two of “get started with Forms” until MS find themselves.

@sichy I can safely say I have a very professional Xamarin Forms LOB app targeting, iOS, Android and UWP in production. There are some pain points of course, but it allows me as a solo dev to support my relatively small company in a way I never thought I could. That said...I would also love catalyst support so I could add macOS to our supported platforms. Disappointed it isn't in the works yet.

[kcrandall]

+1

[papafe]

+1

[dhohlin]

+1

[centerax]

👍

[artem-hryb]

👍

[nor0x]

+1

[costoda-ey]

really would like support for Catalyst

[gdignard]

Today's announcements really don't sound like good news for native development generally, and probably Catalyst specifically.

Reading between the lines, it sounds like MAUI is a doubling-down on XAML as the targeted mechanism for cross-platform support and in the absence of any news otherwise, I would suspect that that focus on that and Blazor will remove much if not all remaining oxygen from other cross-platform technologies.

"Native" Xamarin may continue to exist as foundational technology required for the XAML universe to link to the underlying OS calls, but hope for anything beyond that (such as Catalyst) is probably optimistic.

I would love to be wrong on this, but it really doesn't sound good.

[Uncommon]

What are today's announcements?

[mrwcjoughin]

https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/

https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/it does mention that the full API's for iOS and Android will be available, so hopefully macOS as well

Thanks,

Matthew Joughin Founder / CTO

+27 81 529 7169 http://www.adaptableapps.net

On Tue, May 19, 2020 at 6:59 PM David Catmull notifications@github.com wrote:

What are today's announcements?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/xamarin/xamarin-macios/issues/6210#issuecomment-630950681, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOGERUICCKK3UZSDDYFFWLRSK3G5ANCNFSM4HUBE3KA .

[awaescher]

To me, MAUI sounds like a great step further from Xamarin.Forms, continuing being native.

I don‘t think this is bad news, in fact I think it‘s great news. Microsoft is going to add desktop support for Windows and macOS to Xamarin.Forms. This might not be with Catalyst but will help getting our apps to the desktops 🥳

[sichy]

Any forms is just subpar to native, any approach like this will fail in the longrun and is not worth the effort.

If catalyst is not going to be supported, fine, good to know, but MS should not be surprised if people will start dropping Xamarin altogether for Swift and Kotlin, I see it around me in teams all the time.

-- Pavel Sich

On 19 May 2020, at 19:35, Andreas Wäscher notifications@github.com wrote:

 To me, MAUI sounds like a great step further from Xamarin.Forms, continuing being native.

I don‘t think this is bad news, in fact I think it‘s great news. Microsoft is going to add desktop support for Windows and macOS to Xamarin.Forms. This might not be with Catalyst but will help getting our apps to the desktops 🥳

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[mrwcjoughin]

What you mean adding support for desktop ? Xamarin.Forms has had macOS, Windows 10 and even Linux support for ages already ???

On Tue, 19 May 2020 at 19:35, Andreas Wäscher notifications@github.com wrote:

To me, MAUI sounds like a great step further from Xamarin.Forms, continuing being native.

[image: image] https://user-images.githubusercontent.com/3630638/82358739-3bfb6080-9a07-11ea-955f-caca8c69b88a.jpeg

[image: image] https://user-images.githubusercontent.com/3630638/82358753-3f8ee780-9a07-11ea-8786-32b31020ff5c.jpeg

I don‘t think this is bad news, in fact I think it‘s great news. Microsoft is going to add desktop support for Windows and macOS to Xamarin.Forms. This might not be with Catalyst but will help getting our apps to the desktops 🥳

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/xamarin/xamarin-macios/issues/6210#issuecomment-630970873, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOGERXFT3DKG2RK2355TJTRSK7NHANCNFSM4HUBE3KA .

-- Thanks,

Matthew Joughin Founder / CTO

+27 81 529 7169 http://www.adaptableapps.net

[gdignard]

@awaescher, I'm glad for you that this is great news for you and perhaps even for everyone for whom XAML is a sufficient technology. That doesn't make it great news, though.

With XAML as the foundational design, then MAUI is simply a rebranding for the next iteration of Xamarin.Forms.

Catalyst is not simply targeting macOS. It's being able to run iOS apps on a Mac. There's an enormous difference. UIView and NSView are obviously similar in intent and even to some degree API, but being able to write a native app targeting UIKit rather than AppKit is an incredibly enormous advantage.

I can continue to target Android, macOS, iOS individually given the linking/mapping that Xamarin continues to provide. However, for Catalyst we need tooling and additional coordination between msbuild and Xcode. Despite the promises that this would eventually be supported, the fact that as of December 2019 (the last update we've been given) the relevant tickets have not even been opened with the teams whose engagement would be needed.

I definitely don't consider it great news. It's news targeting the lowest common denominator.

[sichy]

Exactly. That os the whole point. Forms is simply subpar in comparison to native IOS and Catalyst to target macOS out of the box.

The fact that over a year of mentioning this and it is not still even commented, just gives everyone indication on how Microsoft feels about it in general.

Which is fine for them maybe, but other dev teams might (mine certainly does) see it as being left out.

Simple as that.

-- Pavel Sich

On 19 May 2020, at 20:38, Gilles Dignard notifications@github.com wrote:

 @awaescher, I'm glad for you that this is great news for you and perhaps even for everyone for whom XAML is a sufficient technology. That doesn't make it great news, though.

With XAML as the foundational design, then MAUI is simply a rebranding for the next iteration of Xamarin.Forms.

Catalyst is not simply targeting macOS. It's being able to run iOS apps on a Mac. There's an enormous difference. UIView and NSView are obviously similar in intent and even to some degree API, but being able to write a native app targeting UIKit rather than AppKit is an incredibly enormous advantage.

I can continue to target Android, macOS, iOS individually given the linking/mapping that Xamarin continues to provide. However, for Catalyst we need tooling and additional coordination between msbuild and Xcode. Despite the promises that this would eventually be supported, the fact that as of December 2019 (the last update we've been given) the relevant tickets have not even been opened with the teams whose engagement would be needed.

I definitely don't consider it great news. It's news targeting the lowest common denominator.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.