It looks like the iOS app uses a different algorithm for checking, character counts in posts. Drafts and the web (and Gluon for fun) agreed that is 299 characters, but the app thinks it’s 308. I assume that no matter which method I use to publish, it would adhere to the non-truncated rules but I guess I don’t know for sure.
I will say that the discrepancy sows doubt about how it will be displayed on the timeline when I’m getting near that 300 character limit. (An ironic outcome considering the content of the post in which I declare that native apps tend to provide the best creation tools. )
I've always considered myself an app-first guy. But I might be turning into a web-first devotee. I still think native apps offer the best experience for creating and consuming, but I've come around to the idea that the "one true source" should live online where everyone can get it. Still pondering…
I haven’t confirmed this, but my guess is that those quotes around one true source get rendered into " to be counted as six characters instead of one. Different Micro.blog clients might use different Markdown renderers that yield different HTML. The web client, for example, uses showdown, while the iOS app uses markdown-it. Here’s my test showing Markdown rendering using markdown-it:
This is something @vincent or @manton might want to look into and harmonize between the official clients.
Off-topic regarding your post… An interesting observation is that lots of “native” apps today are actually web apps – more or less. The Micro.blog iOS app is one example, built with React Native. Sure, some parts of the app call out to native code, but most of it is written in JavaScript. As we see in this thread, for example, the code responsible for rendering Markdown to HTML and calculating the post length is written in JavaScript.
Yeah, @sod is right it’s probably the quotes. It’s a bug that we can fix. The web and Mac app should have correct counts in my testing, so I think this is just something on iOS we need to fix.
The frameworks (developer tools) that enable developing apps using web technologies (JavaScript) often showcase apps built with them on their websites. Here’s React Native’s showcase page and ditto for Electron, for example.
Some apps you may have used or heard of include 1Password, Discord, Facebook, Figma, Messenger Desktop, Microsoft Teams, Notion, Obsidian, Signal, Skype, Slack, and WhatsApp.
There are many, many more examples. I want to emphasize that there’s a range when it comes to how apps use web technologies. Some are almost 100% web apps, just wrapped in a thin package to be able to ship the app via App Store (and Google Play) and at the other end, you have apps that make use of numerous native features and use JavaScript mostly as “glue”.
This was my understanding that they did the bare minimum and put a wrapper around their we apps which ended up as neither-here-nor-there in terms of UX. But the examples you offered are good apps.
React Native apps are kind of unique because they use web technologies but they aren’t web apps. There doesn’t have to be any actual web views in the app. Electron apps like Slack by comparison are almost all rendered via web views.
I’ve always thought of Micro.blog’s apps as hybrid apps: the timeline uses web rendering but many other parts of the apps are completely native. Most of the Mac app is native and written in Objective-C. Most of the iOS and Android apps are JavaScript.
Yeah, as long as the developers and designers know what they are doing, the choice of native vs. cross-platform development shouldn’t affect the user experience too much. It’s possible to build cross-platform apps that are a joy to use and native apps that suck. And vice versa.
They can be web apps if you want them to be. Just like you can target iOS and Android, you can build React Native apps that target the web.
But I see your point; you can’t just extract HTML, CSS, and JS from the iOS build as that one makes use of native UI controls. You have to make a separate build targeting the web.
We live in a weird age where the lines between web apps and native apps are pretty blurred. For example, just like we can build smartphone apps that use native UI controls and JavaScript, we can develop apps for web browsers that, instead of client-side JavaScript, use C, Ruby, or any language via WebAssembly.
However, I also strongly believe that the ceiling is higher with native apps. In other words: the best native apps are better than the best electron/RN apps.
But an important point, for smaller shops like Micro.blog, is that the latter is way more effective to make and maintain. So if they’d spent the same amount of time/budget on making native apps for every platform, the end result would probably be worse.
)
Just like you can target iOS and Android, you can build React Native apps that target 