Go be a SwiftUI developer right now... Have fun. It will make you appreciate what you have in FileMaker, when you are sitting there writing code to update the screen and move the cursor one half-width character to the right and determining when it needs to reflow.
I'd refrain from making a layout-based argument when FileMaker still can't do dynamic portal row height or a simple grid layout.
And forget anything even approaching Compositional Layout (demos start at 14:00 and get really interesting at 38:00). And this isn't even SwiftUI. Compositional Layout is plain vanilla, standard Swift.
Oh, I'm not talking about the possibilities and functionality of SwiftUI ( though it's got a long ways to go for complex use ). In the grand scheme of things, many of those functionalities bring only a limited value, limited in that dynamic portal row height doesn't help a company make more money, nor does a grid layout, etc, etc, etc.
Agreed, at least re: SwiftUI. I know folks with SwiftUI apps in the App Store already, but it's only been around 8 months and doesn't have feature parity with apps made using Storyboards. For some apps, that won't matter. I could have built my FM Partners app in SwiftUI (I considered it). I just wanted to get it shipped. My Art Con app, by comparison, wouldn't be a good SwiftUI candidate at all, due to my use of CollectionViews.
I imagine SwiftUI will be ready for prime time for WWDC 2020 (June). The Compositional Layout sorcery I posted above isn't part of SwiftUI. That's just regular old Swift.
We may have to disagree on whether or not a visually rich UI translates to profit. A lot of companies could just run their business with Excel, but FileMaker provides significant value, by presenting business data in a more useful and productive way. I see native apps as one more step up that same value ladder.
Are you talking internal applications or client facing apps?
For internal, while I agree the bad side of UI and UX can have a tremendously negative impact...spending 2-3x the dev time on eye-candy alone simply isnāt going to bring the same ROI. But Iām also not talking about an all with no or no design thought out into it.
For client facing stuff, sure, the visually rich interface is very beneficial. But we are talking FileMaker...so inherently and typically, inward facing. Thatās all Iām driving at. The automation and workflow problems have a much larger ROI.
As for mobile apps, still so many companies that are desktop driven, with some mobile component. We built an app with just the iOS SDK. Important for us are things working as expected. Outside of that, nothing stopped us from delivering a superior UX, while only spending minimal time on the coding of the UI side. That brings us back to client or internal facing apps.
I was also careful to talk specifically about SwiftUI. In any case the problems so many devs deal with, we donāt. I suppose one has to figure out what their pain tolerance is for different āmissing featuresā. That will be so different for each of us. I have a funny story about my boss and his toleration of desktop notifications and scrolling lists that Iāll tell another time.
I'm not thinking internal vs external so much. Here are a few things that come to mind, for me. Animations and transulcence? Definitely eye candy. I wouldn't consider drag/drop into a split view controller on an iPad to be eye candy. That's a big time usability increase. Ditto leading/trailing swipe actions or 'long press' contextual menus. I think stuff like that is just as important as the jump from keyboards to mice. Or the distance between the usability of a one button mouse to a multi-gesture trackpad. Or the difference between simple spreadsheets and a FileMaker portal.
If I put a rudimentary iOS app next to an advanced FileMaker Go app, the difference isn't as stark. But an well made iOS or macOS app uses frameworks that simply aren't available in the FileMaker platform. Background sync, effortless scrolling of thousands of rows of related data (object faulting), actionable notifcations with dynamic payloads, integration with other 'Kit's like iCloud. And sometimes a grid layout is the best UI for diplaying product images or document thumbnails. When I develop using some of these techniques, I come back to FileMaker and I groan a little bit. I still love the platform, but the more time I spend in Xcode, the more that gap widens.
What you say about coding in a way that avoids to go and change things in many places can be because you know enough to do that. I donāt. As a novice I do not know how to go about that. Advanced developers like yourself can work around those inconveniences. Citizen developers not so much. Consequently, because we donāt know all the quirks or subtleties of FileMaker, our solutions end up clunky, far from optimized. As we get better our efforts to replace stuff and structures are not supported by facilitating tools.
With my FileMaker clients who want to stick inside FMP but need other functionality, better performance, or similar, I help with the heavy lifting by setting up services callable with a simple INSERT FROM URL.
Often, the performance improvements alone are 400X.
It only takes a few minutes to set up a micro-service and add on to it as needed. I have services that have been running since 2004. For a particular long-running service, have upgraded the Java version and MySQL along the way, but the services have kept running reliably with a client who never even has to think about them.
Now that I can fully get behind. I think there is still some debate around applications that require some level of accuracy, and in the a mouse usually wins, but the use cases for that are slim, and I can fully stand and applaud your answer.
This is just a time and experience thing. Familiarity and a little guidance. Over time you begin to see things differently. I started as a citizen dev, hacking my way through my first app. We all start somewhere.
I know folks with SwiftUI apps in the App Store already, but it's only been around 8 months and doesn't have feature parity with apps made using Storyboards. For some apps, that won't matter. I could have built my FM Partners app in SwiftUI (I considered it). I just wanted to get it shipped. My Art Con app, by comparison, wouldn't be a good SwiftUI candidate at all, due to my use of CollectionViews.