The Journey of Meebox

Hello everyone, I am ⌈LuGuo⌋, a middle-aged programmer who has been drifting in Beijing for 12 years, and also the developer of Meebox.

After graduating from university, I joined a state-owned enterprise and then switched to a cybersecurity company after two years, responsible for developing cybersecurity apps. I stayed in this company for 10 years (I admire myself for being able to stay in one company for so long, haha), and I transformed from a spirited young man at graduation to a middle-aged man with a family.

As I approach the end of my career as a programmer (at 35), looking back on my career, it seems quite ordinary. I used to think about doing something different, but it was just ideas without actions until one day, something happened...

Inspiration from Life

My colleague, Xiao H, is a somewhat handsome young man, though not very young (compared to us old folks), he's quite experienced in driving.

There's a new female programmer in the company, let's call her Xiao W.

The story starts with Xiao W borrowing Xiao H's phone to debug a program. Some of you might have guessed how the story unfolds from the introduction, but let me narrate it anyway.

In the morning, Xiao W demonstrated a new feature to me that required a real device demo. So she borrowed both mine and Xiao H's phones (two phones of different brands). I was watching on the side, testing on my phone without any issues. Then it was Xiao H's phone's turn. As Xiao W switched applications during testing, she smoothly scrolled through the app list. As the scrolling slowed down, a scene that only an experienced driver would understand froze on the screen, but Xiao W reacted quickly, swiftly continuing to scroll through the app list, pretending not to notice.

Haha, it was so embarrassing! 😱😱😱

I couldn't help but think, thankfully Xiao H wasn't around, if he had seen that scene, he'd probably shut himself in.

At noon, I told Xiao H about it, and he was shocked too. He told me that maybe living with his girlfriend recently had exhausted him, and his memory had declined. Otherwise, with his level of expertise, he wouldn't have been so careless.

Truly a seasoned driver, he started drifting right away.

In the evening, while having dinner with Xiao H, he told me about something embarrassing that happened to him just after graduating from college. Though not as awkward as the morning incident, it was embarrassing enough for Xiao H.

After graduating from college, Xiao H bought an Android phone and took some photos with his girlfriend, just normal hugs and cuddles. When he went back home, his cousin came over and saw his new phone, curious to try it out (because his cousin also wanted to buy a phone and wanted to see if Xiao H's phone was good). Without much thought, Xiao H was about to hand over the phone when suddenly he remembered that he had been looking at photos of his girlfriend earlier. If his cousin saw them, the whole family would know because the elders were chatting nearby.

Panicked, he awkwardly said he needed to save some information first, and quickly deleted all the photos of his girlfriend. Then he handed the phone to his cousin again, at which point Xiao H could clearly see the strained expression on his cousin's face.

Listening to his story, I thought it was a miracle that this kid had survived until now. 😅

As a mobile app developer, it's common for colleagues to borrow phones for debugging. I had thought about developing an app to prevent others from peeking at the privacy on the phone, but as mentioned earlier, it was just an idea, nothing more.

After these two incidents, I began to think, should I take action and create this thing?

Even if there's no market, it would still be great for personal use.

But then, I pondered, how to prevent others from seeing the photos on the phone?

• Don't give your phone to others: But there are certainly exceptions, like when your significant other wants to check.

• Hide the photos: This is a good method, and Android also supports hiding photos (not showing them in the gallery), but for a programmer who knows Android development, it's easy to uncover these hidden photos. But who happens to have a programmer friend who loves to peek into people's albums!

• Hiding photos might work, but what if you're viewing a photo and suddenly someone asks to borrow your phone (and you have to lend it)? You don't have time to swipe away the opened photo, so you can only lock the screen in a hurry. Would you dare to unlock it under someone else's gaze?

• Encrypting photos is more advanced, it can prevent your nosy programmer friend from peeking into your album, but it still doesn't solve the case mentioned above.

If all these cases were solved, would that be enough?

So, a simple requirement emerged:

1. The application can hide or encrypt photos.
2. The application can preview photos.
3. The application needs to monitor screen changes and immediately stop photo preview when it's not visible.

Further Refinement of Requirements

To prevent nosy programmer friends from peeking into the photo album, photos need to be encrypted before being saved on the phone.

Since encryption is involved, decryption is necessary for previewing. Therefore, a complete encryption and decryption system needs to be designed, and luckily, my years of work experience come in handy.

Since encryption and decryption are required, they can also be applied to other types of data. It's too simple to just encrypt photos; we can include videos, files, and even text.

If text needs to be encrypted, saving it as a file wouldn't be suitable, so an encrypted database would be necessary.

With these considerations in mind, a rough product concept emerged:

1. The application needs to set a master password, which will serve as the root password for all data.
2. The application supports encrypting text, photos, videos, files, and other data types.
3. It's preferable for the application to run offline, as others might not trust that the app is innocent.
4. Photos and videos should be viewable within the application, supporting both photo viewing and video playback.
5. Upon detecting screen lock or app switch, the application's lock screen should appear, and the preview image should be set as invisible in the app list.
6. Since all data is encrypted, adding a password feature seems feasible (though who would trust an app developed by someone whose app's innocence isn't believed by others? 🐶🐶🐶)
7. Another important point is preventing familiar people from peeking, such as your significant other.

Based on these points, requirements were continuously refined and modified. Once the requirements were finalized, the entire application's encryption protocol was designed, forming a complete closed loop:

• The master password is the root password.
• All data encryption is inseparable from the master password.
• The master password does not directly participate in data encryption.

Users only need to remember the master password and ensure that it's complex enough to ensure sufficient security for the data.

Why is it sufficient security rather than absolute security? Because the master password mode cannot prevent familiar people or your significant other from accessing it. 🐶🐶🐶

Research on Similar Products

After finalizing the requirements, the next step was to research similar products. Since I use a Huawei phone, I downloaded about a dozen similar products from the Huawei market and some from Google Play, totaling approximately twenty. After testing them, only nine were retained (I won't reveal the names of these apps; just search for "encrypted albums," "vaults," "private albums," etc., on various markets to find the most downloaded ones).

The rest were either too simple in functionality or had excessive advertisements and were uninstalled. Most of the retained apps have downloads exceeding a million, with one on Google Play having over 50 million downloads. For a utility app, this is quite remarkable.

Through using these apps, I summarized the characteristics of this type of app:

Innovative Features

• Rich disguise methods, such as disguising as a notepad, calculator.
• Support for screen lock, support for alarm mode, such as taking automatic photos after consecutive wrong password attempts.
• Ability to backup data to the cloud.
• Support for decoy password mode.
• Support for data migration.
• Support across different platforms.

Areas of Discontent

• In the aspect of encrypting photos, either it's not encrypted at all, or encryption is a paid feature 😅😅😅
• Most only support photos and videos, with little support for other types of files.
• Non-members almost always contain ads, and a few apps severely impact usability.
• Most lock screen passwords only support digits and only support 4-digit passwords.
• Fingerprint unlocking is either unavailable or a paid feature.

After a simple use of similar products, I didn't find one that satisfied me. It's probably because I have a lot of requirements and a bit of OCD.

These apps have such high download numbers, indicating that they have been recognized by users. It's necessary to acknowledge others' excellence. ❤️❤️❤️

Finalized Requirements (So Far)

Through research on similar products and combining my own ideas, I have finalized the main requirements for the application:

• Support for memos, currently limited to simple text and not rich text, but memos can have images added separately.
• Support for password management.
• Support for creating photo and video albums, with the ability to set covers for albums and perform simple editing on cover images.
• Support for importing photos and videos, with videos supporting segmented saving.
• Support for file management.
• Support for screen lock.
• Support for offline mode.
• Support for preventing familiar people from peeking.
• All data (including thumbnails) is encrypted and saved.
• No support for app disguise.
• No support for cloud backup for now.
• No support for importing via camera.
• No support for decoy password mode.
• No support for data migration for now.
• Currently only supports the Android platform.

These are the main points. Surprisingly, I haven't adopted most of the advantages of other similar products. Haha, quite rebellious. 😅😅😅

Why haven't I humbly learned from mature products in the market?

Firstly, I personally value user experience, so currently, there won't be any advertisements.

Secondly, for the camera feature, it doesn't seem very practical and would also require camera permissions, which would increase users' mistrust in the app.

Then there's the decoy password mode: It might work against ordinary people, but for those who are tech-savvy or have used similar apps before, it would be easily recognizable.

Other features like app disguise, data migration, and support for other platforms (mainly iOS) can be considered for the second phase, if I survive until then. 😅😅😅

Cloud backup? Who knows when that'll happen.

Prototype Design

Using a prototyping tool is simple, but designing a reasonable prototype isn't. I used Adobe XD initially, but it often had issues, so I synced my data to MasterGo, where I've been using it ever since.

From conceptualization to final draft, I revised the prototype no less than five times, and I still wasn't entirely satisfied with the final version. I showed the final draft to a QA colleague who had left, and she directly said to me, "Clearly a programmer; this design is too 'straight male'." Well, when you're doing everything from start to finish—requirements, prototype, coding, slicing, server—there's not much time left for beautifying the prototype, right? Don't expect too much.

Actually, it's just that I don't understand aesthetics. 😅😅😅

There are a total of 130+ pages of various designs and logic operations, but after some trimming, only 60+ were left.

This is from a mid-stage revision, already exceeding 130 pages.

Let me share a few prototype images and humbly accept everyone's criticism. 😅

Quite 'straight male', isn't it? Well, that's how it is with straight male aesthetics. 😅

Technology Stack

Finally, we've reached my favorite stage. After finalizing the prototype, it's time to start coding. Before that, we need to decide on the technology stack. For mobile development, cross-platform development is definitely the first choice. After all, one codebase for multiple platforms means relatively lower costs.

For cross-platform development, Flutter is undoubtedly the top choice. That's what I went with, but let me tell you, there are so many pitfalls with this thing. What's the worst part? It's definitely upgrading Flutter versions. Every time you upgrade, there are bound to be issues—either libraries aren't compatible or something's throwing errors. So, never follow the trend of upgrading Flutter every time a new version is released. Trust me, it's been tears all the way! 😅😅😅

After quickly developing a demo and running it in release mode, I noticed frame drops or stuttering in Flutter's ListView scrolling (especially with different item layouts). However, with Flutter's upgrades and performance optimizations over time, this issue should be resolved.

Coding

Nothing much to say here. Instead of watching videos during my spare time, I just kept coding. And during holidays, I wrote even more. On and off, it took about a year to complete the main features. There were several rounds of rebuilding during this time, but I finally finished it. Some non-core features can be left for later iterations.

Summary

During the coding phase, as functionalities were implemented, I often wondered if the app had deviated from its original track. After all, my initial goal was just to hide some critical data to avoid the embarrassment of lending out my phone. Because after completing these main features, I added some complementary features and found that the app now exceeded my initial goal. It was heading towards being comprehensive, including features like a password manager and a file manager. Each of these modules could be a complete app on its own, but they ended up being integrated into this app.

During development, I often visited websites for independent developers or observed their discussions in groups. Occasionally, I saw discussions about such apps. Once on V2EX, I saw a post where someone wanted to develop a password management app and asked if people would pay for it. The responses were all negative, absolutely not.

This got me thinking about my own app. Users have no reason to trust your app, do they? Passwords are crucial; they relate to one's life and wealth. I don't trust apps from big companies, from abroad, or open source projects. So why would I trust an app developed by an independent developer like you? It's simply not possible!

Although I know that what I develop is definitely secure and won't pry into users' privacy, why should others trust you? Put yourself in their shoes. If someone else developed a password management software, I'd probably respond like those users, with a definite no.

To prevent the password management module from becoming a white elephant, I later refactored it and added a password hint mode. Basically, you don't need to enter the complete password; just a few characters are enough. These characters serve as a hint.

For an ordinary person, although they have dozens or hundreds of accounts, they usually only have a few passwords (they'll forget if there are too many). So by providing users with a hint, they can naturally remember what the password for that account is. Of course, this doesn't apply to randomly generated passwords.

You could say that this password hint mode alleviates the user's crisis of trust to some extent.

But honestly, even if you try your best, those who don't trust you still won't.