381–390 of 405 posts
Earlier quoted context omitted.
I think it's still annoying. When reading, I often look at where the scrollbar is to get an idea of how much reading is left. Right now, the scrollbar is so thin that I have to waste time looking for it. On a 34" monitor, it's very annoying.
Fair enough! I've expanded it by default on bigger screens now. :)
Earlier quoted context omitted.
If you’re an indie dev, that can be a good thing. I find it much simpler to ship for iOS and Mac as a solo dev.
Yes, initially it is easier, but it is more difficult to scale to other platforms later on. It's all dependent on how much work you want to do upfront versus in the future.
Trying to build for multiple platforms is a lot of overhead, not to mention UI paradigms don't always map one-to-one. Even building for both Mac and iOS (versus just iOS, for instance), for me, can be challenging since there are enough to differences between the two platforms in terms of UX that I have to take extra care to nail both experiences faithfully.
Earlier quoted context omitted.
Yes, initially it is easier, but it is more difficult to scale to other platforms later on. It's all dependent on how much work you want to do upfront versus in the future.
As an indie dev, I feel like the greater risk is that you aren't able to release an MVP and find PMF at all, so I'd always err on getting something working on fewer platforms first so you can move quickly. Having the option to go multi-platform later is a good problem to have, but isn't guaranteed, so don't tackle it early on. Trying to build for multiple platforms is a lot of overhead, not to mention UI paradigms do…
Earlier quoted context omitted.
App store, just charge your lifetime price, instead of free with IAP. So you'd have 2 apps listed: - Paper (Lifetime) ... $99 - Paper ... Get Companies can buy employees the first one because it has a price. > Everything is done via the built-in, robust App Store mechanism that just works. Good call, and so true.
> So you'd have 2 apps listed Hm. I feel like having 2 apps could confuse some users. But maybe it's worth it. ¯\_(ツ)_/¯
This has been going on a long time, once upon a time it was used for Free with Ads versus Paid: https://www.kodeco.com/2404-how-to-create-both-a-paid-and-li...
See also this discussion, mentioning family sharing though instead of mentioning corporate purchasing: https://apple.stackexchange.com/questions/243954/which-purch...
I'm not at work so I can't readily pull up a list of the apps we can and do buy employees thanks to having a paid version available, but there are quite a few, and they win out over more popular apps that have only IAP.
I searched for "Pro" and found a sort-of example:
- Korg Module (Get+IAP): https://apps.apple.com/us/app/korg-module/id1048875111
- Korg Module Pro ($39+IAP): https://apps.apple.com/us/app/korg-module-pro/id932191687
(These are not productivity apps for employees like companies are looking for, just an example done at both price points.)
Anyway, if you had a $99 paid version, our company would buy copies for employees.
Earlier quoted context omitted.
It's a crowded market, but it IS a market. In fact, crowded markets are the ones that work the best. If people find their app, like what they see, and are willing to pay the price, what is your objection exactly?
> If people find their app, like what they see, and are willing to pay the price, what is your objection exactly? My more general objection to your question is that I don't consider individual preference, or individual choice, or individual action beyond criticism, just because the individual is "fine with it". People can "find a product, like what they see, and be willing to pay the price", and the purchase could st…
Looks nice and kudos for sticking with Objective-C. Still a nice language which compiles quickly (well, any language compiles quickly compared to Swift). The visuals and attention to detail reminded me of Bvckup ( https://bvckup2.com ). Downloaded the app to check the "smooth caret" somebody mentioned, started typing and got interrupted after 3 words by a popup telling me to check out PRO features. Oh well. Next, a O…
I'll think about delaying that popup. :)
I should delay asking about notifications as well. It's for the support chat that I mentioned in the article. If I write back in that chat, I fire a local notification. Makes sense more sense to ask for that permission only when the user has written something to the chat.
Earlier quoted context omitted.
It's a crowded market, but it IS a market. In fact, crowded markets are the ones that work the best. If people find their app, like what they see, and are willing to pay the price, what is your objection exactly?
> If people find their app, like what they see, and are willing to pay the price, what is your objection exactly? My more general objection to your question is that I don't consider individual preference, or individual choice, or individual action beyond criticism, just because the individual is "fine with it". People can "find a product, like what they see, and be willing to pay the price", and the purchase could st…
I would have words for such viewpoints, but for the sake of a civilized conversation, I won't express them here.
Earlier quoted context omitted.
> So you'd have 2 apps listed Hm. I feel like having 2 apps could confuse some users. But maybe it's worth it. ¯\_(ツ)_/¯
It's not confusing. They show up next to each other when you search. One is "free" showing "GET" and offering usually ad supported + IAP. The other is paid, with a special logo, saying life time purchase, no ads, or etc. You can link to each other and talk about the other. This has been going on a long time, once upon a time it was used for Free with Ads versus Paid: https://www.kodeco.com/2404-how-to-create-both-a-p…
I think the regular, unsophisticated user might still be confused. I already envision questions like: "Should I buy a lifetime license in the free version or the paid pro app?". There are also additional hurdles like, for example, reviews being divided between 2 separate apps. I don't know, maybe it's worth it, but I am hesitant. I want to keep the whole experience of Paper simple, and this just adds complexity. I would prefer to wait for Apple to solve this at some point in the future.
Paper does support family sharing, by the way.
Earlier quoted context omitted.
As an indie dev, I feel like the greater risk is that you aren't able to release an MVP and find PMF at all, so I'd always err on getting something working on fewer platforms first so you can move quickly. Having the option to go multi-platform later is a good problem to have, but isn't guaranteed, so don't tackle it early on. Trying to build for multiple platforms is a lot of overhead, not to mention UI paradigms do…
Yep that's true, but it's still another reason I'd use Flutter or React Native simply because they make building for even one platform much easier than Swift, in my experience. Then you can build up afterwards because they also make building for other platforms easier too. It's just one reason why Electron for example is well used in companies.
There’s also the whole third party dependency mess referenced in an earlier post, which is unavoidable with both — anything more involved than “hello world” is going to have a mile long list due to how barebones the frameworks themselves are.
Earlier quoted context omitted.
As an indie dev, I feel like the greater risk is that you aren't able to release an MVP and find PMF at all, so I'd always err on getting something working on fewer platforms first so you can move quickly. Having the option to go multi-platform later is a good problem to have, but isn't guaranteed, so don't tackle it early on. Trying to build for multiple platforms is a lot of overhead, not to mention UI paradigms do…
Yep that's true, but it's still another reason I'd use Flutter or React Native simply because they make building for even one platform much easier than Swift, in my experience. Then you can build up afterwards because they also make building for other platforms easier too. It's just one reason why Electron for example is well used in companies.
Many B2B apps are built as plain web apps that run in the web browser and connect to a backend (CRUD apps). That's because business customers care less about the presentation, and more about the value that the software might deliver. If it saves them time or money - they will buy it no matter what the UX is. And many of them even prefer a tab in the browser, since they do their work in the browser anyway.
With B2C users often expect a more polished experience. More often than not they pay for a nicer, more polished thing, rather than for something that solves a particular pain point. Of course, the app should be useful, but that's table stakes. The deciding factor often becomes the UX. Thus in B2C, the client technology plays a bigger role. Depending on how many competitors offer a native UX, the users might not even consider you if they see that the app is not lightning-fast or has some weird, custom UI that looks off.
React Native has some native UI elements, but then many other things such as the navigation stack are reimplemented from scratch which results in a UX that appears to be similar, yet may work in weird ways that differ from native behavior. Plus React Native is pretty slow in my experience, and like any cross-platform thing has a ton of other weird edge cases and annoyances.
I have not used Flutter, but from my understanding, they have reimplemented the whole UI stack from scratch, and draw everything on a low-level graphical canvas. This means that it is even less native than React Native. They emulate/copy the native UI, but it is not the same. Not to mention that they have to do a ton of work to keep up with the latest changes in Android and iOS. Feel free to correct me.
For B2B, React Native, Flutter, or even Web/Electron are perfectly fine. For some less competitive B2C categories as well. For super competitive ones native is almost always a requirement.