[xcode11-feature] Research SwiftUI

[chamons]

In Xcode 11 Apple announced a new UI toolkit, SwiftUI.

It is built in Swift and depends on a number of features such as Associated Types and property wrappers that may be difficult to reflect in C#.

There is also some tight integration with Xcode between a preview render view and the simulator.

Research needs to be done to even answer simple questions such as "what would SwiftUI in C# mean?"

As a friendly reminder, an issue card is not a guarantee that a certain feature will be done, or done under any particular time frame. Issues allow us to document what features we do and do not have, and give the community a place to provide feedback.

[wjk]

IMHO, bridging SwiftUI into C# is not worth the effort at this time. I’ve experimented with SwiftUI, and even when used in Swift, it is too fiddly and complicated a library for me to use effectively. Furthermore, at least on macOS, SwiftUI is quite buggy and not nearly as fully featured as native AppKit. For example, it is impossible to give a button a key-equivalent (so you can make it the default button) is impossible using SwiftUI alone; I had to bind NSButton using the NSViewRepresentable protocol to get it to work. Thankfully, AppKit/UIKit are not going away in favor of SwiftUI (yet…), so not being able to support SwiftUI on day 1 is not that big a blocker. Hope this helps!

[bspinner]

@chamons @wjk Any updates on this? Buggyness and feature incompleteness might be true for now, but it seems Apple is taking SwiftUI seriously and it might replace UIKit in the future. Being unable to use it by then would be embarrassing ("sorry customer, we can't use that fancy new UI feature because it requires SwiftUI. We can't use that with Xamarin.")

[t9mike]

SwiftUI [ ... ] might replace UIKit in the future.

I would have thought SwiftUI is primary syntactic sugar around the various UI APIs, but unfortunately with watchOS it appears there are already new features that can only be used with SwiftUI:

https://developer.apple.com/videos/play/wwdc2019/219/?time=106:

And on watchOS, it means that we have a whole new UI framework. And with it comes some really awesome features, APIs, and just a whole new world of possibilities for things that you can build. For example, with Lists, we finally brought support for swipe to delete and drag to reorder. And with SwiftUI's powerful animations, you can create completely complex, interruptible, and custom animations happening right on the watch.

[motoko89]

I would have thought SwiftUI is primary syntactic sugar around the various UI APIs, but unfortunately with watchOS it appears there are already new features that can only be used with SwiftUI:

https://developer.apple.com/videos/play/wwdc2019/219/?time=106:

This is very problematic for Xamarin iOS developers who wish to have companion WatchOS app (not the full standalone one). I don't feel like Xamarin invests enough into WatchOS at the moment

[davidortinau]

Hi all, I would like to hear more about your needs for watchOS. We want to properly understand the impact and the opportunity. Please shoot me some background on what you’re building or planning to build for watchOS. david.ortinau@microsoft.com

[kamalkumar1]

in the future in xamarin.ios have support for SwiftUI?.

[JelleDamen]

As a Xamarin Native dev, I would love to see the possibility to use SwiftUI (swift) files within my Xamarin/Xcode project. Because I'm using Xcode for my UI, the designer preview in Xcode itself is sufficient. What is the road map for this feature? @davidortinau

[JelleDamen]

Is there someone from the xamarin team that has the answer? Would really love to know if there are any plans regarding swiftUI

[migueldeicaza]

Hello,

Yes we have been researching how to surface this. We have a prototype that can bind a single control now - still more experimentation is needed for how to beat bind SwiftUI

[NSGangster]

@migueldeicaza let us know if there is a branch of xamarin.iOS you can link for testing/improvements. Would love to see the implementation pattern/approach you guys are going for.

[bardigolriz]

Hey @davidortinau @migueldeicaza,

I'm feeling good that this is being reviewed internally with signs of progress being made.

I'm touching base because WidgetKit announced yesterday at WWDC 20 appears to be SwiftUI only: https://developer.apple.com/widgets/. I know discussion above suggested that the lack of SwiftUI capabilities is beginning to impact Xamarin developers with an Apple Watch commitment, but this is going to impact Xamarin developers across the board. For example, the app I'm working on currently will suffer greatly against its competitors if it doesn't ship with a home-screen widget.

I hope I have made a misunderstanding and this won't actually be the case. But if I'm right, then I hope something can be done, all pun intended, swiftly :) The thing is, SwiftUI clearly remains the future for iOS development, and, in fact, observing the iOS indie developer community, at least, it seems to becoming more and more popular for active development.

🤞

Best, Bardi

[davidortinau]

@bardigolriz yes, we are tracking the Swift and SwiftUI impact on frameworks in Xcode 12.

We are tracking progress on the major announcements in Xcode 12 here #8931

[giuseppenovielli]

Come on Xamarin!! 😄

[idchlife]

I really home SwiftUI bridge or something can be made in Xamarin. We are relying on widgets too! But can't prepare anything for it yet. I suspect Xamarin news and roadmap for updates will be near the actual out of beta release

[t9mike]

Another WWDC, another summer of kicking myself for being lazy and using MonoTouch back in the day for my 5 year old app instead of sucking it up and learning Objective-C. I just did not think through the headaches I would have year after year. I can't debug my watch app on device. Watch tooling is a mess. I can't use newer SwiftUI-only features. And now my users will be dragging me saying "where is the widget version" of my iPhone/iPad app (I have a Today Widget). I should have known better, but it still stings.

Do not make my mistake (I doubt many have): do not use Xamarin unless you must have cross-platform. It does not make any sense if only targeting a single platform (like my app is).

[motoko89]

It's really "between a rock and a hard place". I was using Swift back in the early day and the constant change in the syntax, although an improvement, costed me a lot of time to keep up. At the end of the day, I would only complete coding for 1 platform. Xamarin, on the other hand, saved me a lot of time on that front. But it's always 1 (or many) steps behind the latest cool features. If only there is a way to mix between native code (not just framework) and Xamarin :)

[programmation]

What's to stop Xamarin supporting the Swift language (and Kotlin/Java for that matter) directly? Isn't Xamarin in the compiler business? We already have P/Invoke, and Xamarin already wraps the "native" libraries so they're callable directly from .NET - so why not enable Swift/Kotlin code in a Xamarin solution (I'd accept it as a separate project if necessary) that compiles to binary (perhaps using Xcode/Android Studio) and is available automatically to .NET code via a generated P/Invoke-type interface? Has this been done already?

[chamons]

So let's set aside SwiftUI for a second, which is unique as it leans heavily upon a Domain Specific Language as well as large part of the swift language. Let's just call exposing it in particular "non trivial" for now.

The question then reduces to "Why isn't Xamarin working to expose Swift code to C#" - which I'll answer with "We have been for years, and it's actually really tricky". Our work is even in the open - it's called "Binding Tools for Swift".

You can read both Steve's blog post and the technical documents for specific details on why it's so hard, but let me hit some high points:

• Unless you use the @objc attribute, swift generates codes that is not directly callable from Objective-C, but it turns out it isn't easily callable from C or any other language as well. It has it's own custom calling convention, and you can't "just use p/invoke" to call swift unfortunately. Throw in things like the calling conventions for Swift's closures and things gets seriously tricky. Swift makes it somewhat easy to call other langauges, but outside of @objc has no interest in makes itself easy to be called.
• Swift has language features that do not align well with C# as a language. One, which I'll use for examples, is Associated Types. You can think of them as "type shaped holes" which will get filled in later with a specific type. They are not the same things as generics, see Apple's docs for more details. See this PR for some details on the rather inspired mapping Steve came up with.
• A third point which is easy to overlook is that the ABI and API of Swift was significantly unstable for most of the time we've been working this problem. Every single major and even minor release of Swift would change both the internals and externals of the language, and require significant work "catching up".

In short - we have been and still are actively working on supporting Swift in Xamarin. It turns out to be a hard problem, due to design decisions Apple made, but we're making major progress.

[motoko89]

Is it possible to ask for Apple (internal) support? Since Microsoft and Apple have cooperated in the past

[programmation]

@chamons those details are very helpful, thanks! From those blogs & tech info it sounds like you're collectively working on the kind of thing I was thinking about. Nice to know I'm not so crazy after all (or perhaps we all are).

[idchlife]

@chamons thank you for clarification and professional response!

I will try to explain the urgency and need for strategic information about Xamarin features future from me and colleagues and our friend-companies using Xamarin point of view.

The thing is, I love C#, I think it's THE programming language. And it's getting better every new release. I think it is way superior to Swift language.

And I love making mobile and native macos apps using C#, because it has so many features, so many ways to code with pleasure.

I'm new to Xamarin, I'm using it for only a year. I did not witness Xamarin iOS without ability to create watchOS apps, Today Widget extensions. And I heard that Xamarin team worked hard but unfortunately delievered features much later than was needed. Basically - for me the past year was a golden age of Xamarin. I am a huge fan and I like that I'm able to develop apps for iOS with my favorite language.

Before iOS 14 I was creating watchOS and today widget extensions for my apps, which in fact resulted in better reviews, better user coverage, because some people actually bought the apps for ability to work with them with apple watch and with today widget on lock screen. And I suspect my apps had better chance to appear in search results and in top lists thanks to "cool new apple features" implemented in them.

Right now I am seeing that new features (WidgetKit, AppClips) are would be an essential addition to my existing apps, which will result in better reviews and would again improve coverage. Slightly, but even a small contribution, small new iOS specific feature makes a difference. In a long run this would improve everything.

I am thankful that Xamarin team works really hard trying to implement new features and connect with apple apis. But unfortunately we are kinda in the dark right now for the release date and/or plans about these features.

Forcing us to make the choice, whether to port existing apps to Swift language or to wait and see what will happen. Our competitor apps that use Swift will for sure implement those cool new features, making our apps worse choice for the end user.

If Xamarin would have subscription plans like Unity has - I would gladly pay for it. Because this technology is amazing. To be sure that Xamarin will thrive and have many features on time and help it to improve - of course I would pay for such thing.

I'm not asking for answers right now or something because I understand that Xamarin team has limited resources and does what it can in the best way possible.

With my comment I'm trying to justify the nervousness and blatant comments/posts like "without this I don't know how to develop further with your technology!".

We are very grateful for your work and just trying to figure out how to obtain those new cool features in time as Swift developers will.

By the way, maybe I'm not aware and such subscription already exists? Or monthly donation to Xamarin team or something.

[davidortinau]

But unfortunately we are kinda in the dark right now for the release date and/or plans about these features.

@idchlife you'll find the status of our intentions for the features you've cited here: https://github.com/xamarin/xamarin-macios/issues/8931

Forcing us to make the choice, whether to port existing apps to Swift language or to wait and see what will happen

If your main app needs SwiftUI specifically, I'd be curious to to understand that need better. Please elaborate.

If the desire for SwiftUI is the fluent syntax and state management, then you'll see our investment in .NET MAUI as the path for .NET developers.

For extensions and things such as WidgetKit we are looking at how to empower you to write those in Swift/SwiftUI and package them with your Xamarin.iOS project. I appreciate these have high value for your apps and business. For the grand majority of companies that we serve, our focus is on client app development where the critical investment and code sharing occurs.

I'm trying to justify the nervousness and blatant comments/posts like "without this I don't know how to develop further with your technology!".

If we don't support SwiftUI then you won't use .NET? Please elaborate on this as well.

By the way, maybe I'm not aware and such subscription already exists? Or monthly donation to Xamarin team or something.

We don't do subscriptions. To support these projects, any open source contribution is the way to go. ;) If a feature or API or framework is important to you, please contribute and support it.

[idchlife]

@davidortinau

If your main app needs SwiftUI specifically, I'd be curious to to understand that need better. Please elaborate.

If i'm not mistaken, WidgetKit would require SwiftUI to create widgets. I can't actually tell about specific application, but imagine a company which apps have these categories: utilities, helpers, information providers, habit watchers/improvers. They are shipped with paid subscriptions. For those kind of apps today widgets and watch extensions often provide greater user interest. It's not much, but as I said those users can become more loyal and appreciate these apps more because they provide these handy features (today widgets, widgets, watch extensions). And in positive predictions more people would start using apple watch and today widgets.

I'm not actually that interested in SwiftUI itself, I'm interested in creating things that require SwiftUI. I'm not a fan of a fact that WidgetKit cannot be done without SwiftUI but well, that's the way the life goes.

If the desire for SwiftUI is the fluent syntax and state management, then you'll see our investment in .NET MAUI as the path for .NET developers.

I'm a fan of Xamarin Forms and I saw MAUI syntax. I think this is wonderful thing and I cannot comprehend how much work do you guys do to morph Forms into MAUI, but I think result will be astounding.

For extensions and things such as WidgetKit we are looking at how to empower you to write those in Swift/SwiftUI and package them with your Xamarin.iOS project.

You mean having 2 projects - Xamarin iOS main app + Swift/SwiftUI widget kit in one .NET solution? I think this will be a nice way to handle those new features early, not trying to create "SwiftUI bridge in Xamarin.iOS" etc. If it's possible it would be a decent approach - to write almost everything in C# except small parts with SwiftUI just for the interface and parent app shared data consuming. I think this would solve "WidgetKit problem" at least for my cases.

For the grand majority of companies that we serve, our focus is on client app development where the critical investment and code sharing occurs.

That's the reason I and my colleagues adopted Xamarin in first place. Sharing code is a wonderful feature, especially when creating backend and reusing models as POCOs and some utility classes. Since then I look into other approaches (swift/aspnet backend; swift/python backend) with "meh" face, because it's a magic moment - to be able to code in one language, in one place and have almost everything you need for proper good running mobile app with server backend.

If we don't support SwiftUI then you won't use .NET? Please elaborate on this as well.

Imagine company that have major income from creating clients projects. For events, tv shows, brands etc. Often those clients request new features that they saw somewhere (WWDC for example, or their colleagues told them) and they desire that those features will be in their newest apps. This company would require to develop apps with those features. If current tool would not support those features, tool must be replaced because it's the company income at stake, and client must be happy. I know potential projects that already require widgets because well, they require them 🤷 And sometimes those apps that need these new neat features - already coded and running on a daily basis on numerous users phones. And they may be done in technology that does not support new features. Often it's a mess, trying to justify total rewrite in new technology. For example one client once asked about using CoreML features for quick object recognitions offline. They had developers that provided CoreML models for this task. I'm not a Flutter developer, but I suspect if we use Flutter we would have a bad time trying to marry those 2 things together. And with Xamarin iOS we just coded in C# using Apple CoreML + Vision documentation + Xamarin iOS sample projects. It felt almost surreal being able to use such a native feature alongside our C# project code filled with different nuget packages.

Personally I am a huge fan of .NET ecosystem and I often feel sad that I did not adopt .NET technologies earlier in my work. If some projects would require jump to Swift/SwiftUI I would still try to create other projects using .NET technologies. Due to some circumstances I have somewhat freedom in technology choice. Many companies and developers don't. Often lead developers or even product managers would just ask: "is it possible here?" and if they will get the no answer they can cut ties with previous technology and force developers to adopt new, for example developing only in Swift because "there won't be such problems anymore".

I hope I answered your questions :)

[t9mike]

If you are developing an iOS only app, Xamarin is a bad choice. Every year you will hit new roadbumps. Some due to Microsoft not putting sufficient resources in an area (e.g. not fixing fatal issues with watch storyboard editing) and others issues due to significant changes by Apple (e.g. SwitftUI only features). If iOS only, do not let your love of C# sway you into selecting Xamarin. My feeling is the pain points are starting to increase exponentially every year. A Lot of great folks work on the teams for sure and have helped me over the years, but IMHO Xamarin iOS is a crumbling house of cards.

If you are doing cross platform, then Xamarin may still be a good or best choice (I have not kept up in that area). But you must be open to the fact that every year you may have some pain. Sometimes it will be minor. Other times, very disruptive depending on the change and your app / business model.

These are the last two commits to my repo. Fun!

[giuseppenovielli]

@chamons @davidortinau if we can't provide C# binding for all code for a library (i'm not think only about SwiftUI but in general), for at moment, waiting for https://github.com/xamarin/binding-tools-for-swift, can we create a middle .swift file that expose some api of a library (of SwiftUI for example) and this are callable from object-c and so can binding into C#?

Like this https://github.com/xamcat/xamarin-binding-swift-framework

PS. I am not an expert but is only an idea.

[chamons]

Yes, today you can absolutely create a swift "interface layer" which re exposes the API as @objc, which is how we recommend people bind Swift libraries today.

[giuseppenovielli]

@chamons @davidortinau If Apple continue with only Swift without the possibility of Binding into C# with Obj-C, how can maintening binding?

Today there are already RealityKit, ClockKit and WidgetKit with only Swift....

Thanks for all you work!!

[chamons]

Work continues on the project to bind Swift into C#, though the general problem is very difficult for a number of technical reasons.

Creating a Swift interface later marked with @objc simplifies the problem to one you can solve today with Obj-C binding project (which is why it's recommended).

[giuseppenovielli]

@davidortinau Sorry if i insist but our company use Xamarin Forms as main product and so, i ask you, there are not issues for support for MAIN FEATURES and others as possible, of Xamarin.iOS if Apple, in future switch completly on Swift?

I'm a little worried about it.

Thank for all work!!

[davidortinau]

@giuseppenovielli this (some possible future where Apple switches everything to Swift) is why we are developing Binding Tools for Swift, to enable easier binding of Swift only frameworks. As @chamons said, this can be done today most successfully by creating an Obj-C interface and binding that.

[giuseppenovielli]

What about this repository? -> https://github.com/chkn/Xamarin.SwiftUI

[mrlife]

@giuseppenovielli this (some possible future where Apple switches everything to Swift) is why we are developing Binding Tools for Swift, to enable easier binding of Swift only frameworks. As @chamons said, this can be done today most successfully by creating an Obj-C interface and binding that.

@davidortinau @chamons Hi, looking at the repo, it's hard to tell if this is something that's still in progress. In general, is this still the current plan for bringing in any packages that are not currently supported by MAUI?

[damianubp]

@giuseppenovielli this (some possible future where Apple switches everything to Swift) is why we are developing Binding Tools for Swift, to enable easier binding of Swift only frameworks. As @chamons said, this can be done today most successfully by creating an Obj-C interface and binding that.

@davidortinau @chamons Hi, looking at the repo, it's hard to tell if this is something that's still in progress. In general, is this still the current plan for bringing in any packages that are not currently supported by MAUI?

There is also this effort which looks more active: https://github.com/dotnet/runtimelab/tree/feature/swift-bindings