Hi there ! Machato dev here.<p>Honestly, this is my first macOS app and I&#x27;m a bit out of ideas when it comes to performance. If anyone has tehcnical knowledge about SwiftUI and how I could improve performance, please do contact me ! ([email protected])<p>My experience has been that the SwiftUI Profiler shows that almost all processor time is spent deep inside SwiftUI&#x2F;AppKit primitives, despite there being close to no updates to view properties.<p>I&#x27;m glad HN is enjoying the app despite those issues. I promise I&#x27;m doing my best !

First of all, congratulations on publishing your app! I’ve never come close to that, although having created a few PoC’s.<p>On my 11 Pro the animations are sluggish, buttons presses are missed when switching from plan to browse and the device gets pretty warm indicating heavy cpu usage. I’ve read that you’ve already put a lot of time in investigating performance issues, so is then expected with a more complex UI, is this the best one can do with SwiftUI, or do you need to be an even more experienced expert in SwiftUI to further improve things?

&gt; Hard disagree on this. I can&#x27;t think of any IDE that performs as badly, or is as unreliable as Xcode.<p>Well then, great material for an interesting dialogue :)<p>&gt; Intellij is significantly more complex and its still more responsive. (And its reliably responsive. I&#x27;ve never experienced typing lag in intellij on my M1).<p>I don&#x27;t know if even the full IntelliJ is more complex, but it is at least <i>quite</i> complex while being reliable, and deserves a lot of credit for that. I&#x27;ve always defended it, particularly for it&#x27;s robust semantic full project search capability for which it also happens to do better than XCode. If they brought back or renewed a product for building against Apple platforms, I&#x27;d consider it. My main argument is that it would be a truly remarkable feat for any company or project to compete with Xcode and reach close to feature parity without relying on features already part of Xcode. It still supports building and compiling (based on a cursory search) Pascal, C++, C, ObjC, ObjC++, and even Python, Java, and Ruby, simulation on at least 6 different platforms&#x2F;device types, interface building click and drag for mac and iOS, some kind of AR&#x2F;VR environment, and I think is used to build itself. I&#x27;d use PyCharm though if building any sufficiently complex python app, and Android Studio presumably for that, so some of the theoretical capabilities of Xcode are already better served by others. A hypothetical competitor shouldn&#x27;t try to replicate all of those though, instead shooting for a market of anyone who&#x27;s developing for the last 10 years of platforms in just Objective-C, Swift, SwiftUI would be the move.<p>&gt; Microsoft&#x27;s Visual studio (not vs code) is honestly fabulous compared to xcode. VS is of a similar vintage to xcode, with just as many &quot;cobbled together&quot; features added over the years - from VB to C# and .net, winforms to WPF to whatever the latest thing is. But its still fast and reliable. Well, its fast and an order of magnitude more reliable than xcode.<p>You&#x27;re probably right, but only has relatively recently had a mac version, otherwise I&#x27;d be working with what I&#x27;d anecdotally say is just an annoying as hell and unstable OS where all the legacy stuff is still highly visible. I&#x27;ve never pushed Visual Studio hard, but I do recall it being as decent as you say.<p>Ultimately what I&#x27;d like to see is more diversity in the native apple platform dev space, and for the Xcode team to confront the reliability and performance problems you mention and everyone experiences. I believe they introduced a new linker last year for example, and hope to see it improve dramatically. Maybe the right move for them is to build a much more nimble first-party sibling solution. I&#x27;m not even on an M1+ yet, still this shitty Intel thing, and I hear these issues daily when my jet engine spins up.

Hi everyone!<p>We (emergetools.com) just launched our new Snapshots product to help mobile developers prevent visual regressions and confidently build UIs.<p>The coolest part is that we can catch these regressions without devs having to maintain a test suite (this works with native SwiftUI and Jetpack Compose, legacy views do require a wrapper)<p>Our other tools include: - Size Analysis (monitor &amp; reduce app size) - Performance Analysis (prevent &amp; diagnose performance regressions) - Launch Booster (improve your app&#x27;s startup time) - Reaper (find &amp; kill dead code)<p>If you&#x27;re a mobile developer you can try using it by just logging in and uploading a build! I&#x27;m around to hear any feedback

The key point is this:<p>&gt; significantly more potential for performance improvements in the frameworks<p>&quot;Hand-crafted&quot; imperative code will always have more potential, but most code is not this sort of code, and most engineers probably don&#x27;t have the skillset to be able to do this, at least not when traded-off with implementing features and shipping customer value (no criticism, this is likely the right trade-off).<p>Declarative code shifts that control to the platform owner where they can improve things for everyone. Apple has a significant vested interest in this, I&#x27;d say more so than React, as people blame their iPhone for being slow, or their browser, but not React or SwiftUI.<p>I&#x27;d also suggest that most declarative UI frameworks I&#x27;m familiar with have been in higher level languages such as JS, HTML, or QML, or things that run in a browser environment. I&#x27;m not sure we&#x27;ve seen something that&#x27;s in a relatively performant, compiled language, for an environment that assumes reasonable graphics performance.<p>Apple are explicitly targeting 60fps here, it&#x27;s clear performance is a first class concern, rather than just an afterthought, and this is the most convincing case for a declarative UI framework achieving it that I&#x27;ve seen.

SwiftUI might be slower than UIKit at the moment, but it has significantly more potential for performance improvements in the frameworks.<p>With UIKit, developers mostly express the &quot;how&quot; – put this control at these coordinates etc. This makes it quite hard for the framework to a) understand if anything has actually changed, and b) optimise how the UI gets rendered.<p>With SwiftUI, developers much more express the &quot;what&quot; – show the user this information, with these constraints, etc. This allows the framework much more scope to optimise how the layout is accomplished. For example a List of 3 items could skip a bunch of complexity around the handling of swapping views in and out of the hierarchy as it&#x27;s unlikely to scroll far enough.<p>Additionally, by making the data model a first class concept more than it was with UIKit, SwiftUI has much more understanding about data flow and when the UI needs to be re-rendered, or which parts need to be re-rendered.<p>It&#x27;s still early days, compared with the maturity of UIKit (which stems from AppKit, which is 20+ years old at this point), but the scope is much deeper and I&#x27;m confident the performance will improve as Apple iterate, and as they understand how it&#x27;s used by developers and improve those code paths.

Interesting take, but SwiftUI and Combine are really bad. They claim ‘functional programming’, but there’s so much (leaky) magic involved. The sub par automatic code generation yields slow and laggy experiences. I don’t think Apple has any plan to improve this beyond ironing out obvious bugs and waiting for natural performance yields to kick in.<p>It is bad enough that it reminds me of Carbon and the related legion of missteps that hurt Apple badly some 20 years ago and pissed off a lot of loyal developers.<p>Honestly, SwiftUI combined with Apples now complete market dominance is enough to make me reconsider my career path.<p>Just because they’re so big doesn’t mean they can do no wrong and several of their recent technologies have been regressive.

Kotlin &amp; Fritz2. I had to make some difficult decisions with the startup I&#x27;m a CTO of last year. I had a pretty junior team that knew Android, Kotlin, and a bit of server side Kotlin. Then for various reasons we decided to do web, Android, and IOS. So, web based development was a foregone conclusion as we did not have the bandwidth to ramp up separate teams. I did not have the resources to grow the team. And I did not want people to get side tracked learning a lot of new things.<p>Normally, I would have gone down the typescript + react route. I&#x27;m a backend developer but I&#x27;ve done some frontend projects with it before. But I was the only one on the team with relevant skills here.<p>So, instead I salvaged what I had which was lot of Kotlin know how in the team, a Kotlin multiplatform library that we built for Android already (api and model classes), and a Kotlin backend. So, I took a calculated risk of picking Kotlin-js as the main way to do our frontend.<p>I stumbled across a new framework called Fritz2 last year, which is written in Kotlin. I liked what I saw. We did a few spikes end of last year to check if it could do the job and worked as advertised (yes). Then we built a new web app with it in a very short time. I would normally not recommend people take that much risk but in our case it was defensible and it worked out great. In retrospect, we&#x27;ve been very fortunate as this is simply a very well designed framework. At this point we are very productive with it and have a feature complete app that we are putting in the hands of customers. Two months is not a lot of time to pull that off and I&#x27;m lucky with both the team and the technology we picked.<p>What do I like about this:<p>- It&#x27;s just another Kotlin project. That means great tools, great language, and it happens to compile to javascript and run in a browser. We refactor at will, use nice Kotlin DSLs, have autocomplete for just about anything.<p>- Fritz2 is written by a small group of developers that know a lot about frontend development. So you get decent component technology (loosely inspired by react), everything is reactive by default (because Kotlin has great support for that), and they also integrated solutions for things like styled components, using and creating web components. So in short, it&#x27;s a very modern feeling framework that should feel right if you are expecting clean code, components, and sane architecture.<p>- The Kotlin tooling for javascript is pretty great. It comes with lots of ways to integrate with the javascript world. E.g. we integrated leaflet and that was pretty straightforward: add the npm, adapt a few of the typescript mappings. Dukat which is the kotlin type mapping generator that does this automatically nearly worked but ended up generating a few problematic areas. So, I expect this to get better. But manually writing some mappings is not that hard.<p>- Kotlin StateFlows are a great way to represent state. Basically, components subscribe to state flows and respond to any changes you put there. This is a core concept that Fritz2 pushes hard with a concept of stores that store data classes and sub stores that you can derive from that for individual fields. It basically makes you do the right things with your state and you get very type safe and easy separation of rendering code and state management. If you come from Android, that&#x27;s pretty much how things work there as well these days. Also, it&#x27;s similar in newer frameworks like Swift UI and Jetpack Compose.<p>- Fritz2 uses kapt, which a compile time annotation processor, to generate code from model classes to make it easy to subscribe to changes in web components. That gets rid of a lot of boiler plate.<p>- It uses webpack underneath, which gives us a lot of flexibility for how we build our software. We also use cordova to produce native wrappers. With some plugins even.<p>- We use koin for dependency injection. And it&#x27;s just as important of a design pattern in frontend as it is in backend code. Koin is what we used on Android and it&#x27;s a great fit for Fritz2 as well. Nice testable code and we don&#x27;t have a lot of Baron from Muenchhausen style self initializing code (like every messy js project I&#x27;ve ever seen).<p>Things I don&#x27;t like that are long term fixable:<p>- The kotlin-js tooling still has some rough edges. It got a lot better with Kotlin 1.4. though. But undeniably, you will have to do some problem solving when dealing with this. Despite this, we pretty much hit the ground running with this and have not lost a lot of time over this.<p>- Source maps particularly seem flaky. So, debugging in a browser is a bit meh in a browser. If that matters to you, it&#x27;s a problem for now. I expect this to get fixed as they improve the new IR compiler for kotlin-js.<p>- Performance of the build tooling and compiler is not great. In fairness, it&#x27;s not a whole lot worse than the typical webstacks out there. It actually uses webpack underneath. But it&#x27;s definitely not very fast. They do have incremental compilation and usually changes load in the browser after a few seconds. So, that keeps productivity high.<p>- There are not a lot of people doing this yet. So, you need to get creative solving issues. That includes reaching out to developers on the Kotlin slack, digging through OSS code to see how stuff works, etc. The community is very supportive. But if you hit a problem, Stackoverflow does not have all the answers just yet.