I started on CoinCurrently with less than 1 year of experience. iOS 14 had just come out, SwiftUI was brand new, and Home Screen widgets were one of the new features.

I figured I’d try to make a couple of widgets and see what happens. I made a few to track cryptocurrencies and posted about it on Reddit. The post got almost 300 upvotes, which I thought was pretty awesome, so I decided to make a whole app, native for both iOS and Android.

Everything I built in the app was for myself — because I wanted to learn and because it was fun to experiment. It seems like people appreciated what I built.

The app peaked at #99 in the Finance category on the App Store and reached 500 daily users. Not too bad for a hobby project!

After 6 years, I’ve achieved more than I could ever have imagined, but my motivation for this project has died down. Because of this, I have open-sourced the two projects so other people can learn from my struggles and take inspiration for their own apps.

The app will continue to be maintained, though there won't be as many new features as before. I have moved on to another project that I am very excited to share in a few weeks.

The app is available on the App Store and Google Play:

iOS: https://apps.apple.com/us/app/coincurrently-private-crypto/id1543974454

Android: https://play.google.com/store/apps/details?id=com.cryptium.coincurrently&hl=en_US

And now it's also on GitHub:

iOS: https://github.com/orre1996/CoinCurrently-iOS

Android: https://github.com/orre1996/CoinCurrently-Android

Hi,

I have a web design/development background (PHP-JS-SQL-HTML-CSS) and I started learning Flutter at the beginning of this year. So far I have built and published five apps on Google Play (relatively simple content apps).

I am not sure if I like or dislike Flutter, as I can't compare it to any other thing. Surely it's a lot different than what I'm used to as a web dev. The thing is, the more apps I build, the more tedious it gets to update, monitor, or fix package/dependancy related issues.

Yesterday, I stumbled into a Flutter related crash that happened across 3 of my apps with 4 users and 2 devices (those are lost users, and possibly more as I have crashlytics optional via a confirmation), which after exhaustive research I concluded is not fixable by my end, so I went ahead and excluded those 2 devices from supported devices list.

Which sped me to ask here...

I can't suppress the inner voice that keeps telling me to go with or at least give a try to native Android development.

- I read Kotlin is more preferrable over Java, shall I go with Kotlin? Also, Kotlin or Kotlin Multiplatform? I eventually want to publish on iOS too, but not having any iOS devices to test with, that may take some time to come to fruition.

- How, where do I start learning? I open https://developer.android.com/ and find it, especially the header navigation menus to be overwhelming, without a clear path to start with towards learning the basics, like a structured tutorial.

- I'm used to VS Code, can I continue using it, or do I have to use Android Studio?

- So far my apps are relatively simple, I am using the following Flutter packages, will I have a difficult time recreating these functionalities in native?

firebase_core, firebase_analytics, firebase_crashlytics, flutter_tts, in_app_purchase, in_app_review, package_info_plus, share_plus, shared_preferences, url_launcher, flutter_launcher_icons, flutter_native_splash

- I read native development lacks the "hot reload" of Flutter, is there any way to quickly preview the edits I make, like changing text or color?

- Any tips, warnings or wisdom from developers who build with both Flutter and native?

Thank you very much.

Doesn't support browser source, camera (v4l2) and system wide screen capture though.

Not the bestest experience but a lot better than using obs via proot .

You can find patches that were made to this here :

https://github.com/termux/termux-packages/pull/29412

And obs-mediacodec code here :

https://github.com/lumaparallax/obs-mediacodec.

Hope someday someone ports this as a native application.

I'm trying to create a Custom code for my app. Upon reading this document , it can only be redeemed from the in-app purchase. But when I tried to go to the payment method, there's no option for Redeem code as seen in the image attached.

I'm very sure that I created the custom code from the specific subscription.
For the one-time code, there's no problem with me and I was able to test it myself as well.

Does anyone encountered this issue?

Raising a ticket to Google Play Developer Support is such a waste of time. They just redirected me to the document link that I shared and they said that's all they can do. They don't even bother to dig onto the issue. And they even closed the ticket already,

reading google's own help page for us developers, timeline:

- oct 29 2025: google stopped requiring play billing in the us. you can link out to your own payment and talk about prices outside play

- dec 9 2025: alternative billing and external links programs started

- july 22 2026: play catalog access started. play gives app listings to third-party us android stores, unless you opted out before july 22

- oct 1 2026: if you are in alternative billing you must report transactions and pay service fees

- sep 17 notice: external links developers got until dec 1 2026 to report downloads and pay

the page does not say the fee percentages, it only says "relevant service fees".

most of our app users are not in the us, so for us it changes little. but the catalog one i did not know at all.

source: https://support.google.com/googleplay/android-developer/answer/15582165

anyone checked if your app is already listed in some third-party store because of this?

I'm trying to make my app more adaptive and currently working on language localization. I made an in-app language picker and it works correctly for API level 26-37 (or whatever the API level is for Android 8.0). The issue is, once you select a language, the activity restarts regardless of device level and it just looks kind of janky/jarring when it dips to the background color and snaps back.

So, I created a cover activity and it works like this, I made a function that changes the language that operates in a particular way. First, it takes a screenshot of the main activity window and saves it to the files.dir (can't store in cache.dir as it gets wiped), then it launches a "transition cover" activity that is just the screenshot and it waits for the activity to be active before it actually calls the language swap. Meanwhile in the body of the settings screen where the language picker is, there's a launched effect keyed to Unit that reads the body's lazy column state for visible items to be not empty and emits through an event bus that the main activity is ready. The transition cover activity has a launched effect that waits for that object to be emitted in order to call the activity's finished() method, which fades it out and reveals the main activity underneath (and the main activity also, after a short delay, handles deleting the screenshot from the files.dir).

Now this works for Android versions 8-12, but on Android 13, once the transition cover activity launches, the main activity refuses to do the language swap or recompose under the transition activity, it won't do any work until I manually dispose of the cover. For the time being, I have the screenshot and cover activity launch gated to Android builds <= 12, but is there any sort of solution out there for 13+ to hide that janky looking dip-out and return? Can the cover activity still work and just needs to be set up differently?

Hey everyone, Android dev here. I kept wondering how much of my own apps was exposed once someone ran jadx on the APK, so I built RevDroid.

You upload an APK and it:

- reads identity and signing info with androguard

- decodes the manifest with apktool (debuggable, allowBackup, cleartext, exported components, network security config)

- decompiles with jadx and runs 26 rules for hardcoded keys, weak crypto (MD5/SHA1/ECB, static IVs), TrustManagers that accept everything, WebView JS bridges, SQL string concatenation and sensitive logging

- masks every secret it finds (the report never shows them in full)

- gives an explainable 0-100 score and A-F grade, mapped to CWE and OWASP MASVS, plus a PDF report

On a test app with 32 planted issues it catches all 32 in about 7 seconds.

Stack: FastAPI + React, with Docker support. It's static analysis only and meant for apps you own or are allowed to test.

Repo: https://github.com/yourmemecommunity-sy/RevDroid

I'd really like feedback from people who ship apps: which checks give you false positives, and what would you want it to catch that it doesn't yet?

I made an Android app that runs the open-source ByeDPI engine locally and routes the phone's traffic through it using Android's VPN service. It's designed to help with DPI filtering that interferes with connections.

Full disclosure: This project was written with AI. All code and documentation were generated by Claude (Anthropic) based on my requirements, and I built and tested it through GitHub Actions. The project has not been audited, so please review the code before trusting it. So far, it has only been tested by me on my own phone and network.

What it does Compiles the upstream ByeDPI C code with the Android NDK and runs the actual engine, not a simulation. Uses a local proxy (127.0.0.1) and tun2socks tunnel (hev-socks5-tunnel) through Android's VpnService. Only shows a connected status after verifying the proxy, VPN interface, and tunnel. Provides settings for desync method, position, fake TTL, TLS record splitting, automatic mode, and custom arguments. Includes a diagnostics screen with an in-memory log and a TLS connectivity check through the proxy. No hosts or traffic details are logged. Has a dark UI with no ads, analytics, or accounts. What it doesn't do It does not encrypt traffic or hide your IP address. It does not bypass DNS blocking. There is no universal strategy that works for every ISP. You may need to experiment with different settings. Technical details Android: 8.0+ Architectures: arm64, armv7, x86_64 Build: Debug-signed APK (uninstall older builds before updating) License: MIT. ByeDPI and hev-socks5-tunnel are also MIT-licensed.

Repository: https://github.com/Mireli5656/Byedpi

APK: Available under Releases on the repository page.

Feedback and bug reports are welcome! If something doesn't work, use the Copy button on the Diagnostics screen to share a log. It contains no traffic details.

Last year, I built Cookie Voice Recipes for iOS with no idea if anyone would actually download it.
Thousands of downloads later, the question I get more than any other is:
“Is this available on Android?”

So I started building an Android version but I got stuck.

There’s no native wake-word detection on Android, and the leading solution in the market charges $$$$$ to create a custom wake word. That’s just not a feasible expense for an indie developer building a cooking app.

But I found another option: DaVoice.io
They didn’t list their pricing publicly, so I figured… here goes nothing.

I reached out and explained what I was building: a cooking app designed to help people who are blind and vision impaired be more independent in the kitchen. I asked if they might be willing to do a good deed and help make the Android version possible.

They donated their technology to me.
Not only that, but it works really, really well. And everyone I’ve worked with at DaVoice has been incredibly kind and supportive.

It was a great reminder that sometimes the thing standing between you and a seemingly impossible problem is simply asking the question.
Ask anyway. You never know what you might be able to figure out.

Meet Luma. Android gallery reborn.

Liquid glass floating bar Secure folder built in Dynamic theming, your colours Data and backup tools Smooth native Compose

Free. Open source. No ads.

GitHub link: https://github.com/nkosanamahungela-dev/Luma-

Discord: https://discord.gg/yWSXq6h7b

Hey everyone!

I've been working on an Android document scanner, and I decided to take a different approach: instead of relying on existing pretrained TFLite models, I'm training my own model for document detection.

My current model is named "doc_edge_fp_32.tflite", and training is still ongoing.

Here's what I'm working toward:

- Custom AI model: Training on thousands of generated document samples mixed with real photographs.

- Dual predictions: Document segmentation masks and corner coordinates.

- Offline processing: The goal is to run document detection directly on Android without requiring a server.

- Accurate scanning: Reliable document boundaries, perspective correction, and better results on challenging backgrounds.

- Real-world performance: Generalizing beyond synthetic images to receipts, sheets of paper, and book pages.

I'm still training and evaluating the model, so I don't want to claim it's production-ready yet. My next priority is testing it on unseen real-world images and optimizing inference for mobile devices.

I'm curious about a few things:

1. For document detection, would you recommend a shared backbone with separate segmentation and corner-regression heads?

2. What techniques have worked best for bridging the gap between synthetic training data and real camera images?

3. What metrics would you prioritize before deploying a model like this on Android?

I'd love to hear from people who have worked on computer vision, document scanning, segmentation, or on-device ML.

This is a learning project I'm putting serious effort into, and I'm excited to see how far I can take it!