I became a dad not too long ago. Like most new parents, we leaned on apps to help navigate the chaos. My partner used a nursing tracker to log feeding times, durations, which side, all that. Pretty useful honestly.

Then the ads started. Supplements to boost milk supply. Tips for “fixing” nursing schedules. Could be a coincidence. Probably not.

That got me thinking. These apps know a lot. Not just what you tell them but when, how often, the patterns. And most of us just hand that over without thinking twice because the app is helpful and we’re tired and we just want to know when the last feeding was.

I’m a developer. So I built something different. An app that knows nothing about you except what stays on your phone.

AI is Everywhere, and That’s Not Free

Almost every app you use today has some kind of AI feature. Your photos app groups faces. Your keyboard predicts your next word. Your fitness tracker tells you when to sleep. It feels like magic and honestly a lot of it is useful.

Here is what that looks like in numbers. In 2025, people downloaded AI apps 3.8 billion times. Revenue from those apps more than tripled to over $5 billion. The word “AI” now appears in over 100,000 app descriptions on the App Store and Google Play combined. It is not a trend anymore. It is the default.

But here’s the thing. Most of that AI isn’t running on your phone. It’s running on a server somewhere. Your data makes a round trip, leaves your device, gets processed, comes back as an answer. Every single time.

I work on AI for a living. I’m one of the engineers behind Amazon Lens AI. I understand why this is the default. The infrastructure is there, the models are powerful and it works. It makes sense for a lot of use cases.

But it also means your data is traveling. And depending on what that data is, that’s worth pausing on. It has never been cheaper to store, process and make sense of large amounts of personal information. Most companies have good intentions. But intentions and incentives don’t always point in the same direction.

What Does “Private” Actually Mean?

When I tell people I built an app that is truly private, the first question is usually “what do you mean by private?”

Fair question. Privacy gets thrown around a lot. Every app has a privacy policy. Every company says they take your data seriously. But that’s not what I mean.

I mean the information never leaves your phone. There is no server receiving it. No company storing it. No policy to read or trust. The AI that processes your voice lives on your device and stays there.

Think of it like writing something on a piece of paper. Only you can read it. You decide what happens to it. You could share it, store it, throw it away. That’s your call entirely. The app is just the pen.

That’s the standard I built to. Not “we handle your data responsibly.” Your data simply doesn’t go anywhere.

The App

The app started as a simple idea. New parents are exhausted. Logging a diaper change at 3 AM should not feel like filling out a form.

So I built a voice logger. You just talk to it.

• “Poop diaper with a blowout.”
• “3 oz formula an hour ago.”
• “Two hours of sleep.”

It understands you and logs it. That’s it.

The AI that does this, Google Gemini Nano, lives entirely on the device. No internet connection needed. You could turn on airplane mode, open the app and it still works. Your baby’s data never leaves your phone. Not even once.

And when you want to do something with that data, like spot patterns or track trends, the app lets you export it as a CSV file. Open it in whatever spreadsheet tool you like and dig in yourself. The app doesn’t tell you what your data means. It gives you your data and gets out of the way.

Oh and there’s a Wear OS extension too. That one was a game changer for me personally. Middle of the night, hands full, I could just talk to my watch and log it. No fumbling for the phone. The AI still runs on the phone, the watch is just the input, but the two talking to each other worked better than I expected. Honestly one of the more fun things I’ve built in a while.

I think that’s how it should work.

The Honest Part

I want to be upfront about a few things.

Right now the app only works on Pixel 9 and newer devices. That’s just where on-device AI is today. The hardware needs to be powerful enough to run the model locally. It’s a real limitation and I’m not going to pretend otherwise. I’m working on supporting more devices using open weight models, but that’s still ahead.

The app can also make mistakes. You say “poop diaper” and it might log it as a wet diaper. Not a big deal, there’s an edit option. But it’s a good reminder that AI is not perfect and apps have a responsibility to handle that gracefully, especially when the data is personal.

I actually built a feature where you could ask the AI questions about your logs. “When was the last feeding?” Things like that. I ended up pulling it out. The guardrails needed to make it safe and reliable were more than the feature was worth at this stage. That was a deliberate call.

I also had to go through Google Play’s compliance process even though the app has no internet access at all. I was fine with that. App stores pushing for accountability on AI features is a good thing. Builders should have to think carefully about what they ship.

The Edge is Moving

A year ago this app couldn’t have existed. The models weren’t small enough to run on a phone. The hardware wasn’t ready. On-device AI was mostly a research conversation.

That’s changing fast. The gap between what you can do in the cloud and what you can do on a device is closing. And as that gap closes, the excuse that “we need your data on our servers to make this work” gets weaker.

I’m planning to open source this app. Not because I think it’s perfect but because I think the conversation it starts is worth having. If you’re a developer and you’re building something that touches personal data, I hope this is useful. You don’t always have to choose between powerful AI and respecting your users.

And if you’re not a developer, I hope this at least makes you ask the question next time an app wants access to something personal. Not out of fear. Just with a little more awareness.

The technology to do this right exists. More people just need to choose to use it.

Questions to Ask of Every App

You don’t need to be a developer to think about this stuff. Next time you download an app that wants to know something personal, just ask a few things.

• What’s the worst case if this AI gets something wrong? A misread diaper log is harmless. An AI making assumptions about your health, your mood, your relationships is a different thing entirely.
• Does the app give you your data or does it just use it? Can you export it, delete it, take it somewhere else? Or does it live in the app and only in the app?
• Who benefits from what you’re sharing? Sometimes the answer is clearly you. Sometimes it’s less clear. That’s worth knowing.

You don’t have to be paranoid. Most apps are fine. But the ones that touch the most personal parts of your life deserve a little more scrutiny. Especially now when AI makes it easier than ever to do a lot with a little bit of information.

Your Baby’s Data Shouldn’t Be Anyone Else’s Business was originally published in Nerd For Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

The following situation happened to me because I had to use an older version of Picasso-2.5.0. I know, it is way too old. This issue does not exist in the newer version of Picasso(2.8+). But, if you happen to encounter this issue and are looking for an answer, please continue reading.

I encountered an image rendering problem in our production app where some of the images that are rendered by Picasso are rotated counter-clockwise.

While debugging, I found that the Uri that system gives after a user selects an image, differs based on how the user shares the image to the app 🤯

When using a photo picker from an OS 9 Samsung device, the Uri looks like this:

content://com.android.externalstorage.documents/document/primary%3ADCIM%2FCamera%2F20221102_1111610.jpg

When sharing the same photo from the camera app, it looks like:

content://media/external/images/media/335

When sharing the same photo via Google Photos, it will look like:

content://com.google.android.apps.photos.conentprovider/-1/1/content%3A%2F%2Fmedia%2Fexternal%2Fimages%2Fmedia%2F355/REQUIRE_ORIGINAL/NONE/image%2Fjpeg/1763556495

The RequestHandler implementation inside Picasso handles these differently. Anything that doesn’t have media in the path will be handled by ContentStreamRequestHandler which does not look for the EXIF orientation tag.

To solve this, I introduced a new implementation for handling all Uris that has content:// scheme and attached it to the list of request handlers of the Picasso instance.

class LocalImageHandler(val context: Context) : RequestHandler() {

    override fun canHandleRequest(data: Request): Boolean {
        return data.uri.scheme== "content"
    }

    override fun load(request: Request, networkPolicy: Int): Result? {
        val contentResolver = context.contentResolver

        val imageInputStream = contentResolver.openInputStream(request.uri) 
                            ?: return null

        val originalBitmap = BitmapFactory.decodeStream(imageInputStream)
                            ?: return null

        // use androidx EXIF interface library to read the EXIF TAG_ORIENTATION tag
        val exifOrientation = getExifOrientation(request.uri, context)

        if (exifOrientation ==ORIENTATION_UNDEFINED) {
            return Result(originalBitmap, Picasso.LoadedFrom.DISK)
        }

        // refer to utils from Picasso
        // https://github.com/square/picasso/blob/00bc2a4bdc4f18e1b2462c8b909987be73b4fca3/picasso/src/main/java/com/squareup/picasso3/MatrixTransformation.kt#L213
        val rotation = getExifRotationDegrees(exifOrientation)
        val translation = getExifTranslation(exifOrientation)

        val exifMatrix = Matrix()

        if (rotation != 0f) {
            exifMatrix.preRotate(rotation)
        }

        if (translation != 1f) {
            exifMatrix.postScale(translation, 1f)
        }

        val newBitmap = Bitmap.createBitmap(originalBitmap,
                0,
                0,
                originalBitmap.width,
                originalBitmap.height,
                exifMatrix,
                false)
        if (newBitmap != originalBitmap) {
            originalBitmap.recycle()

        }

        return Result(newBitmap, Picasso.LoadedFrom.DISK)

    }

val picassoInstance = new Picasso.Builder(context)
			.addRequestHandler(LocalImageRequestHandler(context))
			.build()

This problem is fixed in the latest version of Picasso. If you are like me, and are stuck with an older version of Picasso, this can come in handy.

Comment below if you have incurred any such issues! I would love to know.

In another post, I’ll write about how I shared the image cache between react native and native Android image rendering.

Write code once, use it twice

React Native is awesome. Businesses drool over the concept of “write once and use it twice” as it drastically reduces the cost and improves productivity.

When building a brand new app, developers often prefer to run the server locally. This comes handy as building new features in mobile app that also requires server changes. Hence, in most cases, the dev app points to ports in localhost. This works great for iOS since the simulator's localhost is the same as the machine's localhost. However, this doesn't work for Android Emulator. We have to modify the host to the machine's IP address to make this work.

Here comes ADB to the rescue…

$ adb reverse tcp:8000 tcp:8000

This enables a reverse proxy between a virtual server in the emulator port 8000 and wires it to the host machine’s port 8000. Now we can run / live reload our mobile app on both platforms without any additional effort. Keep in mind that the reverse proxy will be void if the emulator restarts.

More resources on cross platform development

• Donn Felker’s post — Flutter just might work

Gif credits : giphy.com

Originally published at https://srbkrishnan.dev.

Hello there!

It has been a while since I wrote my last post. I recently started looking into react native development to see why people love it so much. The last time I coded in javascript, it was in 2014. So the things that I am going to share here are from a JS newbie perspective.

First and foremost, I now don’t hate javascript. Credits to ES6/ES2015+ and React. All the destructuring and spreading were confusing at first; however, they make a lot of sense now.

I am going to discuss one minor JS gotcha here and I will continue sharing what I learn in future posts.

Javascript class methods

Classes in JS are new to me, so I went on to MDN see what classes look like.

Let’s create a class:

In your component,

Now when we run the app and press the view, it logs brewing... DarkRoast in the console, which is expected.

Let’s look at a slightly different example where we pass in coffeeBrewer to the component using props and destructure the brew method:

We’d expect it to log brewing... DarkRoast in the debug console. However, it logs brewing...undefined. Coming from a Java and Kotlin background, this was surprising.

To find out more, let print this instead of this.beanName in brew(),

After talking to my fellow JS experts, I understood why this is happening. This is because brew() didn't run in the CoffeeBrewer's context. The function brew doesn't belong to the "class" until you "bind" it.

GOTCHA…

Here’s how you do it

constructor(name) {
   this.beanName = name; 
   this.brew = this.brew.bind(this);
}

This will result in the debug console as

We can also use arrow functions in classes to get this “binding” without doing this.brew.bind(this);

Looks like this is a very common problem in Javascript and yet I stumbled on it despite following the standard docs.

Above examples are ran with the environment :

"dependencies": {

"react": "16.8.3",

"react-native": "0.59.9"

},

"devDependencies": {

"@babel/core": "7.4.5",

"@babel/runtime": "7.4.5",

"babel-jest": "24.8.0",

"jest": "24.8.0",

"metro-react-native-babel-preset": "^0.54.1",

"react-test-renderer": "16.8.3"

}

Of course there are many and even better ways to do this. Which one do you think is best? DM me @srbkrishnan

Resources on ES6 classes:

• Classes vs Prototypes
• Arrow functions and functions in classes

Originally published at https://srbkrishnan.dev.

I’ve come across many infinite-scroll examples for React Native Flatlist with class components. I think function components are the future of react- Why? You may ask. Recently, I’ve been working on React Native projects and have been using function components and custom hooks a lot more than class components. They read better, use less boilerplate code and are easy to test. You can read more about function components here and here or if you’d like to watch, I’d recommend watching this.

Let’s jump into an example.

We will be building an infinite scroll feed using just function components and hooks that shows dog pictures, because I just love these cute creatures :)

Let’s start with the Unsplash API setup. Follow their developer doc to get an API key to fetch photos. Unsplash API supports pagination and have a ton of photos which makes it suitable for our example.

Create an async function that takes in keyword, pageNumber, limit as parameters and returns array of photos.

Now let’s create a custom hook using state and effect hooks to provide data to our Flatlist.

This custom hook relies on the effect hook to call whenever any of page, shouldFetch changes. We use a callback fetchMore to set shouldFetch to true. Note that the shouldFetch has a default value of true. This triggers the initial effect call to fetch the first page automatically.

Also observe the order of setting the states :

1. Set shouldFetch to false
2. Update remaining states setPhotos, setPage

This prevents the effect hook from automatically fetching the next page as we update the page state.

Let’s use this custom hook to display dog images using aFlatlist.

Observe how the photos and fetchMore are used. This will result in an endless feed of dog photos :)

Because hooks are essentially a function, we can mock it out in our tests.

This post covered how to do infinite scrolling in flatlist using function components and hooks. We did not cover error handling and loading state. I will write a separate post to cover loading and error states.

Please leave a comment if you think there are better ways to do pagination using hooks in function components.

Hey, there fellow coffee-nerd!

This post is NOT about how to make BulletProof coffee, but it is about how to make it with the least effort. Yes, including the cleaning part, which takes the most time in the whole process.

Brew your favorite hot coffee by any method. If you are looking for the least effort, use a pour over. Instead of brewing into a cup, I brewed into a 32 oz wide mouth mason jar. The jar gives enough space for the hand-blender to blend your coffee with butter.

Add butter to the jar before brewing the coffee, this helps the butter to melt before you blend. If you prefer adding collagen protein with your BulletProof coffee, add it before you blend to prevent any lumps. While any unsalted butter gets the job done, I use Kerrygold grass-fed butter. It tastes a lot better than others :) After you finish brewing, remove the pour-over and wash it right away.

Most hand-blenders work well for BulletProof coffee. The blender has to run in hi-speed settings to make the coffee forthy and creamy. If you prefer less frothy, run it in low speed settings. Also make sure the blender splits into 2 parts so that it is easy to clean.

Once you are done, remove the blending stick and clean it right away. If it gets dried, it needs more effort to clean!

Now you can enjoy the Bulletproof coffee directly from the jar. I like this 32 oz jar because it can make coffee for 2.

Below are the things in the picture if you like to try out the exact setup. Post on the comments below if there are any other hacks I could use!

Cuisinart variable speed hand blender, BulletProof® The Original Coffee, Vital Proteins — Plain, Ball 32 oz wide mouth jars.

React Native migrated to AndroidX since 0.60. This means if your app or one of your RN dependencies is using any of the Android legacy support libraries, you won’t be able to make it work successfully. Android studio has some tools to migrate your native code to AndroidX. Follow these instructions to get your native apps/libraries migrated to AndroidX 👉 https://developer.android.com/jetpack/androidx/migrate

Note that the jetifier offers migration only for binaries your app depends on, and the tools offered by Android studio offers migration for your source code to AndroidX.

But what about the native modules you install through NPM? These modules are part of the source of our React Native app. We cannot be using Android studio to migrate the app every time we do npm install.

How do we migrate the React Native libraries to AndroidX without using Android Studio?

Most of the React Native developers don’t use Android Studio for coding, let alone migrating the source to AndroidX. React Native community offers this nice little cli tool based on Dan Lew’s script to migrate all our source code to AndroidX including the native dependencies we install using NPM.

If you are using RN 0.61+, this jetify tool is automatically used before all react-native run-android and there is pretty much nothing we need to do to get your app working.

But, what is the catch?

What if you have a brown field app? Do you have an app that is partially React Native? Do you use Android Studio to run/debug/profile your app?

Here is a Pro tip.

Migrating our source code is just a one time setup and pretty much straight forward. It is just the React Native libraries installed through npm we need to take care of. These Native modules are pretty much untouched after getting installed. So the best way to migrate them to AndroidX is to jetify right after installing these native modules.

You probably got an idea where I am getting at,

npm-post-install is your friend. Just add a post-install script to jetify your native modules and we’re good to go. The app should build whether we use react-native run-android or ./gradlew installDebug.

Bonus: This also works if you have a CI-CD pipeline setup to make release builds.

If you are a mobile developer and haven’t tried React Native, you probably should. React Native makes it so much easy to build simple, beautiful apps with almost just Javascript. It also allows developers to write native code for each platform (iOS, Android, Windows and more) and use it via Javascript. These are called Native modules. There are plenty of libraries out there that helps you use some of the key device features such as Bluetooth, Wifi, camera that uses native code and expose interfaces to Javascript via NativeModules fromReactNative module.

Here are some of the popular react-native libraries that are also comes with platform specific native modules

• react-native-firebase
• react-native-ble-manager
• react-native-fbsdk

Prior to RN 0.60, to use a library that is also a native module, we need to add the dependency to package.json and also link it to our native projects so that it is included in our native builds. This can be done either using react-native link <dependency name> or manually if you have super powers.

In case of Android, the linking is as simple as adding the dependency project’s path to settings.gradle and adding an implementation <dependency package> in build.gradle and also include the package in your MainApplication.java file.

For example, if you were to add the library react-native-ble-manager to your project, you need to follow these steps:

Disclaimer : I totally stole these from their README

Add the lines to your MainApplication.java:

Note: This post concentrates on Autolinking on Android, take a look at here for how it used to be for iOS : 👉 Linking iOS Libraries

Basically for Android, there are 2 steps involved in linking a native library to react-native projects . For each dependency,

1. Include the dependency project in settings.gradle
2. Include the implementation <dependency project> in our dependency {…} in build.gradle file.
3. Include the package in our Application class.

As of React native 0.60+, the react-native cli was extracted out and maintained separately into the react-native-community/cli repo which had a major version update. This update eliminates the need for us to manually link the native libraries after adding them to package.json.

Note: RN 0.60+ requires cocoapods for iOS and AndroidX for Android. I will write more about it on a separate post.

For example, if you were to add the same library react-native-ble-manager to your project with RN 0.60+, all you have to do is just add react-native-ble-manager to your package.json. This makes it so much easy to maintain and easily update our dependencies.

How does this Auto-linking work for Android projects?

We discussed how to link native libraries manually prior to RN 0.60. Setting up Autolinking with RN 0.60+ is very similar to the 3-step manual linking for each dependency. Below steps are just a one time setup.

1. Including Project in settings.gradle

Instead of adding individual native libraries to our settings.gradle file, we just include one script native_modules.gradle that comes with react-native-cli 2.0+ and then invoke the function applyNativeModulesSettingsGradle(settings).

2. Include the implementation for each dependency we added

This is similar to the previous step, we include the gradle script native_modules.gradle again and invoke the function applyNativeModulesAppBuildGradle(project) which will take care of adding implementation <dependency project> automatically.

3. Include the package in our Application class.

The native_modules.gradle generates a class called PackageList which has all the dependencies’ packages included. We just need to instantiate this class using the ApplicationContext and return it to the getPackages method of our Application class. If there are additional native modules need to be included, we can just add them to this PackageList instance.

What is in the file native_modules.gradle that makes this process so simple?

We need to thank its Javascript counter part for that. The react-native-cli has this pretty neat CLI tool config. This tool provides us all the necessary information about the react native project including the native dependencies that should be added to our native projects (iOS, Android, etc). This is how it looks for a project that has a dependency react-native-ble-manager :

I removed most of the stuff in this output to keep it short. Take a closer look at the android property of dependencies.react-native-ble-manager.

The script uses this information to auto-link native libraries to our project automatically — for each dependency 🤯

Learn more about Auto-linking 👉 here

Pro Tip: When you migrate to RN 0.60+, you may need to unlink all your previously “linked” native libraries. You can do it by using npx react-native unlink <dependency name> . This removes the entry from your settings.gradle , build.gradle and MainApplication.java . If you have already moved your MainApplication class to Kotlin, then this unlinking will not work. You need to unlink manually, which is the reverse of manual linking.

More Reading: Migrating to RN 0.60+