Xamarin-macios: [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

[phone]
http://www.adaptableapps.net

On Tue, May 19, 2020 at 6:59 PM David Catmull [e-mail]
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 [e-mail] 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 [e-mail]
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

[phone]
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 [e-mail] 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.

[awaescher]

Xamarin.Forms has had macOS, Windows 10 and even Linux support for ages already ???

Xamarin.Forms for macOS is still in Preview. For Linux, there’s a binding for GTK#. In Preview. For Windows, there‘s UWP, yes - and WPF: In Preview and community driven. How does this map to „ages“?

Well, I don’t understand why everyone seems to be so upset but okay, I won’t be able to change that. I don‘t even want to.

[gdignard]

@awaescher Forms abstracts away the OS, and understanding here comes from having extensive experience in coding straight to UIKit, AppKit (and/or Android) and the differences between them.

The fact that you don't even want to understand is disappointing. This is obviously the wrong forum for you.

For anyone else reading who might be coming from a Forms background and who is interested in why this is important to non-Forms users, I'll add a few points about why the impact is significant.

All the operating systems have similarities (and especially UIKit and AppKit of course), and each has significant strengths but each also has idiosyncrasies and drawbacks.

Instead of thinking of Catalyst as allowing iOS apps to run under macOS, perhaps it would be helpful to think of it instead of being able to run UIKit code on Macintosh hardware.

This is different from simply "write once" / "target twice". It's being able to choose UIKit/iOS or AppKit/macOS when writing an app which targets hardware that supports Catalyst. There are lots of apps where the strengths of UIKit are exactly what you're looking for and to be able to leverage those strengths on a widely used and heavier-duty hardware platform is an amazing opportunity.

For those working in a Forms/XAML world, I understand that Catalyst would provide very little difference since the OS is largely abstracted away and indeed that's its intended strength. Someone in that situation will find the MAUI announcement a welcome thing and I'm happy for all those developers.

As I've written before, Catalyst as it stands today I feel is not really ready for prime time and there is still a lot of stuff to figure out before it starts to shine. However, I'm predicting that we'll see a much more mature and robust Catalyst introduced at WWDC 2020.

It's at that point that if Microsoft does not deliver the tooling needed to build those apps that a heavy price will be paid by developers who have chosen the Xamarin route and who are cut off from running UIKit apps on Macintosh hardware.

[awaescher]

@gdignard I do understand the problem here and I do understand the differences between these platforms because I did use UIKit on iOS, AppKit on macOS and native Android apps before I started with Xamarin.Forms. Same on the Windows and macOS desktops. I just didn't understand the negativity I seemed to have summoned. But that's likely to be my fault reacting too positive on your post about MAUI - in the eyes of a Xamarin.Forms guy. I admit that I did not focus on native Xamarin.macOS/iOS development here. Sorry for that.

To me, Catalyst is still a thing. I subscribed to this issue long time ago and am still hoping for it. Really sorry for interrupting, that was not my intention.

[kcrandall]

I think Xamarin.Forms and MAUI are the stepping stone in the abstraction level between developing for each platform and just talking to an AI and asking it what you want it to develop, which will come years from now and people will think it's crazy that anyone ever wrote code for anything as simple as a UI let alone 4 times for 4 seperate OSs. Just the same way we think it's crazy to code a desktop app in assembly today. My opinion is for 90% of apps theres no reason to use something other then a cross platform framework. Xamarin in my opinion is the best because you still have the power to control native very easily and it's not JS and done in a compiled language. There are definitely some things that still need 100% native coding, but for most business apps that's very excessive and a waste of multiple dev teams and huge extra cost. Catalyst is great and I still hope it comes, but in the past few months I've seen more xamarin packages add macOS support which, to most developers, I think will end up being sufficient in the long run. (In my project 90% do or will target macos. Up from 60% at the start of the year.) Microsoft sort of abandoned macos for years in xamarin after the first preview and most open source libs just targeted IOS, Android, and usually UWP. It seems like it once again is going to be a highlight which I see as a good thing. The ability to have resources in one place is good. I think it's the smart long term decision. I think they are going to come out with a drag and drop interface in the future as well and try to get it into a good low code solution, which will make it much more widespread in usage as anyone will be able to make apps with it. But it will always have the power of Xamarin.Forms for developers like is to use.

[cho-trackman]

No matter what there is no reason for Xamarin not to support Catalyst, Xcode is doing the heavy lifting after all.

[divil5000]

The continued lack of Catalyst support with the Xamarin tools is really disappointing. We've been using Xamarin for around eight years for our native iOS app, and a little less than that for Android. These are high-performance native apps and we do not use Xamarin.Forms, though I appreciate that product is sufficient for many apps.

When Microsoft choose not to support Catalyst they are putting companies like mine at a disadvantage due to our original choice of Xamarin. If we had invested in ObjC/Swift we would now have the tools we need to deploy our iOS app on Mac, but as it stands, with Xamarin, we do not and it is costing us.

Microsoft, please get on with helping us support the same things that XCode does.

[michaldobrodenka]

It would be nice to know at least if it is planned.

[sichy]

I think from the state of this discussion, Build keynote and lack of mention of Xamarin “Native” eyc, it is clear it is not planned at all.

On 20 May 2020, at 13:32, Michal Dobrodenka [e-mail] wrote:

It would be nice to know at least if it is planned.

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

[michaldobrodenka]

Maybe they are just waiting for new version of macOS. So this technology will be more mature or something.

But for me is important to know if it is coming. Almost a year ago we told our customers that macOS app is on the way. Now I don't know if invest time and money into building native mac app or wait a few more months. We are a small company, so every dollar wasted has impact on budget.

Xamarin.Forms/MAUI is not an option for me -I don't want to rewrite app into inferior technology - slower, bloated, more bugs etc just to offer mac port.

[Mogikan]

@davidortinau should know that. Could you be so kind to provide any news? Our best educated guess is that they know something will happen at WWDC and they can't provide more info because of NDA.

[mrwcjoughin]

Michael when last did you use Xamarin.forms ?
It is no longer slow or buggy.
I have been using it since 2015 and it has come leaps and bounds. I admit
the macOS target for it is not mature like the other platforms - but it
seems this will be fixed with .net 6 as per the announcements.
I don’t believe they will drop having platform specific UI’s if you choose
at all, but we’ll have to wait for more info to come out from Build before
we know

On Wed, 20 May 2020 at 13:44, Michal Dobrodenka [e-mail]
wrote:

Maybe they are just waiting for new version of macOS. So this technology
will be more mature or something.

But for me is important to know if it is coming. Almost a year ago we told
our customers that macOS app is on the way. Now I don't know if invest time
and money into building native mac app or wait a few more months. We are a
small company, so every dollar wasted has impact on budget.

Xamarin.Forms/MAUI is not an option for me -I don't want to rewrite app
into inferior technology - slower, bloated, more bugs etc just to offer mac
port.

—
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-631423015,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACOGERWILTWKLXVVTTNRDCTRSO7C5ANCNFSM4HUBE3KA
.

>

Thanks,

Matthew Joughin
Founder / CTO

[phone]
http://www.adaptableapps.net

[michaldobrodenka]

@mrwcjoughin it's been 3 years since I tried Xamarin.Forms.

Is CollectionView already supported on mac?

[mrwcjoughin]

@mrwcjoughin it's been 3 years since I tried Xamarin.Forms.

Is CollectionView already supported on mac?

@michaldobrodenka it only supported on iOS, Android and UWP:
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/collectionview/introduction

But their commitment at build yesterday was that macOS will have "Feature parity" - so clearly this will be resolved in .net 6 / MAUI

[michaldobrodenka]

@mrwcjoughin So maybe in future MAUI/x.f would be good technology to start my project with. But now Catalyst would be great.

[mrwcjoughin]

@mrwcjoughin So maybe in future MAUI/x.f would be good technology to start my project with. But now Catalyst would be great.

@michaldobrodenka for sure - I also really want catalyst now as well. In the mean time I just avoid controls that aren’t supported on all platforms

[michaldobrodenka]

@mrwcjoughin Yes, I'm looking forward to see mature X.F.

But my app has about 150 pages and almost all of them are some sort of CollectionView with different widget sizes and layouts.

(That's why I created own multiplatform abstraction of collection View (and platform implementations - RecyclerView, UICollectionView , VirtualizingPanel) and render views natively or using SkiaSharp (most of them)- using my own multiplatform framework on SkiaSharp.)

[Mogikan]

@davidortinau Isn't it a right time to start implementing this Feature after WWDC?

[tekmun]

With the announcement of iOS support on ARM-based Macs, there is no longer a need to support Catalyst. Am I right?
Intel-based Macs will be phased out in next 2.5 years.

[michaldobrodenka]

As I understand it, Catalyst is still a thing if you want to add some mac os features to our ipad os apps.

[Sevenish]

With the announcement of iOS support on ARM-based Macs, there is no longer a need to support Catalyst. Am I right?
Intel-based Macs will be phased out in next 2.5 years.

No. you still need Catalyst for advanced mac integration and features

[sichy]

And because it will be easier than ever to run ios apps on mac, the need for at least minimal integration (file system, menu, hover action etc) will be in even bigger demand.

So no, Catalyst cannot be ignored.

Pavel Sich
IOS BITS LTD
phone: [phone]
email: pavel.[email protected] [e-mail]
web: www.iosbits.co.uk http://www.iosbits.co.uk/

IOS BITS LTD is a limited company registered in England and Wales. Registered number: 0773969. With registered office at International House, Holborn Viaduct, London, United Kingdom, EC1A 2BN

On 24 Jun 2020, at 10:35, Sjoerd van Noort [e-mail] wrote:

With the announcement of iOS support on ARM-based Macs, there is no longer a need to support Catalyst. Am I right?
Intel-based Macs will be phased out in next 2.5 years.

No. you still need Catalyst for advanced mac integration and features

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

[divil5000]

Also, there are many of us that need Catalyst right now and are suffering through not being able to make our iOS apps available on Macs cheaply, due to our decision to choose Xamarin.

The hope of a vague solution in 3 years' time when a majority of users' Macs might be ARM based is not a solution.

[sichy]

@divil5000, exactly this. totally right.

On 24 Jun 2020, at 10:54, divil5000 [e-mail] wrote:

Also, there are many of us that need Catalyst right now and are suffering through not being able to make our iOS apps available on Macs cheaply, due to our decision to choose Xamarin.

The hope of a vague solution in 3 years' time when a majority of users' Macs might be ARM based is not a solution.

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

[Sevenish]

Also I believe the transition time apple indicated is when they will stop SELLING new Mac's with Intel processors. Intel based macs will be supported for many years after that

[michaldobrodenka]

Yes. I thinnk that x86-64 macs will be supported at least 5-8 years.

[Mogikan]

Good to know that this feature at least "in consideration": https://github.com/xamarin/xamarin-macios/issues/8955

[Suplanus]

Good news to this issue: https://www.mergeconflict.fm/225

Frank Got Catalyst for Xamarin.iOS Working!

[gdignard]

Listened to the podcast and that indeed sounds like very very good news!

[michaldobrodenka]

Question is, when we can see it in product (if ever)? From the podcast it seems that it's quite complicated.

[Mogikan]

@michaldobrodenka the question is will it help to persuade MS to plan this feature.

[tougher]

Some of it is here https://github.com/xamarin/xamarin-macios/compare/main...praeclarum:frank-catalyst2 but can't find any changes in the mono repo.

[Mogikan]

https://github.com/mono/mono/pull/20537

[Mogikan]

For those who like me is tracking news regarding this feature seems like xamarin devs are actively working on this feature https://github.com/dotnet/runtime/issues/44882
Thank you guys!