Hey everyone :wave: Do you publish your apps to t...
# feed
s
Hey everyone πŸ‘‹ Do you publish your apps to the Microsoft Store? I recently released my first paid apps Mines+ and Thumbnail Fixer Pro there. πŸŽ‰ When enabling a trial for Mines+, I realized something I had not expected: Even after a trial expires, users can still press the Launch button inside the store and start the app. They can actually keep it forever until uninstalled. That's because the Store manages the license, but it is the app’s responsibility to check that license at runtime and restrict access if necessary. Since the Store API is a C++ / Windows Runtime API designed for native apps, I created a small JNA wrapper so JVM based apps can access the license state (and also open the in-app purchase dialog). If you are publishing a JVM desktop app to the Microsoft Store, this might save you some time: https://github.com/stefanOltmann/msstorelib Hope this is useful for you. Any feedback appreciated. πŸ™‚
βž• 7
K 15
K 2
m
It would be nice if the use of JNA could be replaced by Javas new FFI (aka Panama). That would save you the dependency on the JNA library. As this is most interesting for applications where the JVM is bundled anyway there is no reason to not use Java 25 which includes Panama by default.
πŸ‘ 2
s
You're absolutely right. I could require Java 25. Didn't do that because it's a lib (-> Java 17), but it makes sense to go with Java 25 now. I used JNA because I have experience with it and didn't do any FFI so far, but I'll give Codex a shot and see if that works out.
Proper testing is the hard part for this library. Microsoft allowed me to upload my testbed app to the store, because that API can only be really tested in a production environment.
r
Just curious, how is your experience in the publishing process to microsoft store compared to google play? Was this same or difficult?
s
Way easier. A lot less questions to answer.
πŸ‘ 1
But the Partner Portal is slow and sometimes fails. I guess half of it is vibe coded. πŸ˜„
πŸ˜… 1
s
the partner center really is awful and slow. even worse if you have multiple microsoft accounts, private and organisational (I'm often trapped inside login loops). everything related to azure is pure torture as well. they frequently break something internally, so your publishing CI might hang or fail. feedback for rejected submissions is often sparse and you need to email them. but they are a lot more lenient than apple and don't require 12 testers like google. packaging and publishing is quite complex compared to android but nucleus helps a great deal.
s
Indeed, I've multiple accounts there I didn't want and also "tenants". And there is something called an Enetera ID. That confused me a lot the first time. Once that's sorted out releasing a new app is easier than on Google Play.
s
speaking about compose for desktop about the packaging part ofc
s
Indeed, Elie is our hero. πŸ™‚
πŸ’― 1
r
Hey @Stefan Oltmann
I could require Java 25. Didn't do that because it's a lib (-> Java 17), but it makes sense to go with Java 25 now.
The Java FFM API is Java 22, so you might be able to offer both backends. I'm currently using it and I'm using it and it's quite simple, but verbose, as is typical of Java :v . For my project, I created a Gradle plugin yesterday for the jextract tool to automate it and make it easy to use. If you're interested, let me know and I'll make it public. In my opinion, it's good to encourage the use of recent Java/JDK versions and not continue using the "Java 8 LTS" lol
m
If you have a well-behaved header file which does not pull in god and the world and doesn't need a specific compiler just to be able to parse it, like some Mircrosoft stuff does, then it is almost an automatic process. You run jextract on it and you are done. No extra library needed. It is best to configure jextract such that your lib is loaded explicitly, which actually seems to be the default, because you can then initialize your code like this
Copy code
PDFPageRendererFactoryPdfiumImpl(System.getProperty("compose.application.resources.dir"))
by using the predefined property from Compose. That's best for packaged apps so that you don't have to fiddle with library paths. That way I created bindings for Pdfium by just using the pre-built libs from https://github.com/bblanchon/pdfium-binaries in conjunction with jextract and FFI.
πŸ’― 1
s
What annoys me is that downloads from Microsoft Store sometimes are really slow or installation gets stuck. I think there are a lot of touch points where potential buyers just may give up.
In this case where I installed the trial it was stuck on 100% for three minutes. The next click on the button crashed the MS Store app. After starting the Store app again the installation was done, but people might get distracted and just forget that they wanted to test my game.
s
weird, I never noticed anything like that. the install success rate from analytics is 98% for my app. however, not a paid or trial app
s
s
right hand side
s
The Java FFM API is Java 22
That's correct. I remember that vips-ffm has Java 22 as target. However, Java 25 is the next LTS version. So this should be used I think.
In my opinion, it's good to encourage the use of recent Java/JDK versions and not continue using the "Java 8 LTS" lol
Definitely. I used Java 23 for a long time, because I needed vips-ffm. But now I'm happier that Java 25 LTS is out and I'll stay there. Setting the target there also enforces it πŸ˜‰
s
apparently I also got two bad reviews πŸ˜₯
s
They must be kidding me...
πŸ˜‚ 1
What's your product?
OH... I FIGURED IT OUT.
Games don't have that metric. Just apps.
s
oh interesting
s
First I uploaded my game as "app", because they were not showing the Game category to me... (the whole UI is utterly broken) They accepted updates for 3 months and then suddenly rejected them, because they figured out it's not an app - it's a game. So they made me reupload under a different name, leaving all users of the old one behind.
Compared with Google Play Store & Apple App Store you can call Microsoft amateurs in this game.
But it's the only safe distribution platform I found. They fully protect from chargebacks and I'm in fear getting a victim of chargeback fraud. I'm happy to give them their 15% cut for that.
s
definitely. I appreciate not having those insane apple fees and restrictions but you'd certainly expect better from the official app store for the most widely used desktop os. it still feels like it's in its infancy
πŸ’― 1
that's my app btw https://apps.microsoft.com/detail/9n0r9m9ppc7p (https://fluen.se/en/downloads downloads for other platforms since KMP 😎) I use revenuecat for subscriptions, technically you could also use it for one time purchases but I guess it's not ideal UX compared to paying in the app store and seeing a price upfront before installing
s
How are you able to use RevenueCat? They don't offer a JVM module as far as I know.
s
You have a very nice and clean product landing page. Note to myself: I'll steal that when I find the time.
s
if you mean the website, that's made with kobweb
s
Nice. But I meant more the overall design / apperance.
That looks really polished to me.
πŸ™ 1
I also like orange as CTA color.
Web billing means you build UI in your app and that calls their REST endpoints? Or do you just open checkout in browser?
s
simplicity and some images go a long way, which you can steal from envato for example, there are so many assets. the orange actually comes from the second app for teachers
πŸ“ 1
and no, revenuecat's web billing offers prebuild UI too. you do checkout in the browser
s
I like to see that you've a business and I hope it works out for you. After losing my job two month ago I'm starting right now and can only dream about having such a nice landing page and polished product.
and no, revenuecat's web billing offers prebuild UI too.
But not for Compose, right? That's where I see a gap in their offerings.
s
for mobile they do, not for desktop though. they recognise it and it's on their backlog but they couldn't promise me anything. web billing is purely for the browser, so you simply open the link on the user's device
s
Yeah, that's an issue.
In that case I could also open Paddle, PayPal, Stripe or anything else.
But you talked to them, so they know Compose Multiplatform exists.
s
but you'd need to handle the subscription stuff on your own and revenuecat doesn't take a cut until 2.5k$ a month, so I'm fine with that
πŸ‘€ 1
s
Okay, not taking a cut for revenue I'm unlikely to make... that sounds like a deal. πŸ˜„
s
also it's not really a business, just a student filling my own needs and a lot of fake it until you make it πŸ˜„ #C0BQ5GZ0S sadly isn't that strong for central europe but I hope there are still kotlin offerings around here
true 1
s
@Michael Paus Version 0.2.0 is available now on Maven Central. πŸ™‚ This version uses FFM as requested. Java 25 is required.
πŸ‘ 1
thank you color 1
Disclaimer: I reviewed and cleaned up the Kotlin code, but the C++ part is largely AI generated. I refactored what I could understand, however I cannot confidently say whether it is fully thread safe, free of memory leaks, or free of other subtle issues. I asked Elie to review it to be on the safe side. One immediate observation was that using the currently focused window as the owner/parent for the purchase dialog could be considered a workaround rather than a proper solution. I hope he will have time to look more deeply into the rest of the native implementation. The library worked flawlessly in my testbed application and is now running in production in Mines+, but that does not necessarily mean it is ready for general production use. πŸ™‚ If any C++ experts are willing to review the native layer and validate that it is robust and safe, that would be greatly appreciated. On a side note, this is the first project where AI enabled me to build something I likely would not have been able to implement on my own. It required quite a bit of trial and error to reach a version that compiled and behaved correctly, but in the end it worked. Fortunately the required native code is rather short. πŸ˜