Feem

Feem is a worldwide popular offline-first file sharing app for every platform. No WiFi? No problem. Works with hotspots, 50× faster than Bluetooth, and has resumable transfers — a world-first feature.

Comment

Introduction

Hi, I'm Fritz. I wrote my first lines of code at age 14 on a resource-constrained TI-82 calculator.
On that tiny device, I built a full Minesweeper clone — and even a pixel-perfect replica of Son Goku.
That little hack earned me my 15 minutes of fame back in high school in Cameroon.

Fun times.

Today, though, I want to talk about a very different challenge:
how our everyday devices talk to each other when the internet isn’t available.

This led me to build Feem, an offline file transfer app that pushes the limits of what’s possible in peer-to-peer networking.
My goal is to get you as excited about this problem space as I am.

Agenda

  1. The problem I set out to solve
  2. Why it matters more than ever today
  3. The technical challenges — and the falsehoods I had to unlearn while tackling them
  4. The impact and traction Feem has achieved so far
  5. The future vision for this project

1. The Problem That Started It All

Offline P2P

It all started in Buea, Cameroon, where a simple iPad gift to me from my Swiss friend created an impossible challenge. There was no easy way for me to transfer files from my iPad to my Windows PC over our painfully slow and limited internet connection. And then it got even worse. The government shut down internet access entirely for political reasons.

This wasn't just an inconvenience—it revealed a fundamental computer science problem: how do I enable direct device-to-device communication across heterogeneous platforms and hostile network environments. I became fascinated with building systems that cannot be blocked, leading to an obsession with P2P, offline-first systems and blockchains.

I built Feem to solve my issue of direct device-to-device file transfers: achieving reliable, high-throughput file transfer (300+ Mbps over WiFi vs Bluetooth's 2-3 Mbps) across platforms that were never designed to interoperate directly.

2. Why This Matters Beyond Bandwidth

Edge to Edge Computing

Files aren’t getting smaller—they’re exploding in size. 4K video is quickly becoming standard. Frequent operating system security updates now measure in hundreds of megabytes, while major upgrades span multiple gigabytes. AI models are already hundreds of gigabytes, and companies like Apple are proving that running them locally improves privacy, latency, and cost—an approach others are likely to follow. Even in blockchain, where true decentralization depends on more participants running their own nodes, storage requirements continue to balloon. Yet despite all this growth, we still funnel most of our digital activity through distant servers—wasting bandwidth and exposing sensitive data.

Digital sovereignty is no longer theoretical. Economic sanctions can cut entire regions off from cloud services overnight. Natural disasters — earthquakes, floods, or wildfires — can cripple communication networks in seconds. Just recently, Southern Europe experienced a major blackout that left millions disconnected.

Robots and drones in the future will have to figure out a way to transfer massive amounts of data between themselves while in close proximity.

We need computing that works edge-to-edge, not through centralized chokepoints.

It’s 2025: Why can’t an iPhone directly and quickly send files to an Android device—without relying on cloud servers halfway across the world?

Cross-platform peer-to-peer file systems that work reliably at consumer scale in hostile networks were impossible just a few years ago. No one had solved the fundamental distributed systems challenges of device discovery, file abstraction, and network resilience across incompatible ecosystems.

Today, this is barely possible — Feem is one of the few systems that achieves it in the wild.

Tomorrow, it will be ubiquitous: not just for file transfers, but as the foundation for edge-to-edge computing using hardware we already own.

The market opportunity is massive. The leading offline file transfer app, ShareIt, has billions of downloads simply because it nailed Android-to-Android transfers early on. In many regions, it remains the primary way people share apps with each other — not through the Play Store, but directly via ShareIt.

3. The Technical Challenges

The seemingly simple workflow—discover nearby devices, select files, transfer directly—hides extraordinary complexity:

Core Requirements:

  • Universal cross-platform support. No new hardware. Only use computing devices users already own.
  • File system abstraction across different OS paradigms
  • Robust local network discovery and transfer
  • Intuitive user experience. From the user's perspective, it should just work.
  • Resumable transfers for large files
  • Full-duplex communication
  • Encrypted P2P file transfers without a centralized server

Additional Constraints:

  • Single developer team (labor is also a resource constraint)
  • Constant OS security changes breaking existing functionality
  • Hardware diversity from iOS to Android to Windows desktops
  • Network unreliability in real-world conditions

3.1 Cross-Platform Reality Check

Common Misconceptions: (aka Falsehoods programmers believe about cross-platform development)

Falsehoods cross-platform development

"Native apps are obsolete—everything's web-based now"
Remote web apps fundamentally cannot access local file systems or establish direct device-to-device connections without internet infrastructure.

"Cross-platform toolkits solve everything"
I actually shipped the first versions of Feem with Qt. But licensing changes forced me to reconsider — and even before that, Qt didn’t fully support all mobile operating systems. Years of building cross-platform apps taught me a hard truth: every toolkit lags behind native OS capabilities, especially when it comes to low-level file and network operations. Flutter is an excellent choice today for typical line-of-business apps, and even for some simpler cross-platform file transfer tools. But once you confront the full complexity of modern file systems and networking across platforms, those abstractions start to break down. That’s where Feem had to go deeper.

"Just hire platform specialists"
Human resource constraints also matter. If WhatsApp scaled with only 50 engineers, a focused smart approach for Feem should work with a single engineer.

Solution:

  • Feem's C++ Core Engine (80% of core functionality): Speed, compatibility, unified business logic. I built this engine from scratch.
  • Angular UI Foundation: Consistent interface paradigms across platforms.
  • Platform-Specific Integration:
    • iOS: C++/Objective-C++ engine, Angular + Swift UI, Capacitor bridging
    • Android: C++/Java/JNI engine, Angular + Kotlin/Compose, Capacitor bridging
    • Windows: C++/Win32 engine, Angular UI, Electron integration
    • Linux: C++/POSIX engine, Angular UI, Electron integration
    • Mac: C++/Foundation engine, Angular UI, Electron integration

In building Feem, I’ve had to work across a wide spectrum of technologies: HTML, TypeScript, CSS, C++, Objective-C++, Swift, Java, Kotlin, and Golang (for Feem Pro’s online back office), plus a collection of custom shell scripts for build automation.

To test and refine the app, I invested in a diverse hardware lab: iPhones, iPads, Android phones and tablets, Android TVs, a Nokia Lumia, Windows NUCs, Linux laptops, MacBooks, and an iMac. Feem has literally been engineered, tested, and optimized across the full ecosystem of devices people actually use.

3.2 File System Complexity: The Biggest Lie in Computing

aka Falsehoods programmers believe about files.

The core delusion: "A file is just bytes with a name and path."

Falsehoods Files

Reality on macOS:

  • .app files are actually complex directory bundles
  • .pages, .numbers, .key documents are folder structures
  • Frameworks appear as single files but contain versioned libraries
  • The Finder hides this complexity, but your code can't

Reality on iOS:

  • Photos and videos don't expose traditional file paths—only opaque identifiers
  • A single "photo" can be multiple files (original, edited, live video components, short bursts)
  • Photos might exist only as cloud references, requiring download before access
  • File representations don't have inherent names—you must generate them

Reality Everywhere:

  • OneDrive/iCloud files can appear in directory listings but not exist locally
  • Android/iOS sandbox restrictions prevent direct file access
  • Users expect Photos/Videos transferred to Android/iOS devices to be appear in their Gallery apps.
  • Filename compatibility varies (Linux allows :, Windows forbids it)
  • Sending entire directory trees can overwhelm systems without proper frontend and core engineering.

Solution: I developed a new stream-based file abstraction layer that treats all content as byte streams with metadata, regardless of source:

// Simplified core abstraction
class FeemFileStream {
    virtual ByteStream getStream() = 0;
    virtual FileMetadata getMetadata() = 0;
    virtual bool isAvailable() = 0;
    virtual void download() = 0; // For cloud-backed files
};

class IOSPhotoStream : public FeemFileStream {
    // Handles PHAsset complexity, multiple representations
};

class AndroidMediaStream : public FeemFileStream {
    // Handles MediaStore API, scoped storage
};

class CloudBackedStream : public FeemFileStream {
    // Handles on-demand download from OneDrive/iCloud
};

This abstraction enables uniform handling whether content comes from local storage, cloud services, or mobile photo libraries— this is a computer science problem that most developers never encounter until building truly cross-platform systems.

3.2 Performance Engineering & System Architecture

Building a responsive file transfer system across platforms required solving several low-level performance challenges. We went with a Multi-threaded Architecture with Asynchronous messaging and SQLite Integration.

Feem's C++ Core Engine

3.3 Automatic Network Discovery: Why "Just Broadcast" Fails

Common Misconceptions: aka Falsehoods programmers believe about automatic network discovery.

Falsehoods LAN

"UDP broadcast to 255.255.255.255 works everywhere"
Modern networks block broadcasts. Hotels and corporate WiFi actively prevent device discovery.

"Ping-sweep the subnet"
This is an effective way to get banned from networks and drain mobile batteries.

"Devices have one network interface"
Virtualization, VPNs, and mobile hotspots create complex network topologies on single devices.

"WiFi is ubiquitous and reliable"
Many users rely on mobile hotspots. App backgrounding breaks connections. Network switching interrupts transfers.

"LAN transfers don't need encryption."

They do. A private LAN doesn’t protect you from insider threats or internal theft, especially in shared spaces like offices or classrooms. That’s why Feem uses OpenSSL to encrypt all data transfers and chat messages, keeping your files safe even on local networks.

Critical Discovery: Through extensive testing and user feedback, I found that Windows firewalls caused 90% of automatic discovery failures. Rather than asking users to manually configure firewalls, we integrated directly with low level Win32 APIs to detect firewall settings and provide in-app configuration assistance.

Solution: I developed a multi-protocol discovery system that achieves 98%+ success rates across hostile networks.

The system automatically adapts to network conditions: enterprise WiFi (mDNS blocked, use broadcasts), hotel WiFi (broadcasts blocked, use mDNS), VPN networks (leverage Tailscale for secure internet transfers), Windows networks (firewall detection and configuration).

If your device runs on Windows or Android, Feem allows you to create an adhoc Wi-Fi Direct hotspot that other devices can connect to just by scanning a QR code.

3.4 Frontend: Beyond File Managers

aka falsehoods programmers believe about file transfer UX

Users want to transfer files: Traditional file transfer interfaces assume users think in terms of files and folder hierarchies. Real users want to share content—photos from last week, music playlists, conversation context, APKs on Android for app sharing between devices.

It's OK if default device names are in English: In earlier versions of Feem, devices were assigned random English names like Beautiful Seagull, Smart Kitten, or Big Toad. Many users found these names funny and charming, but a small minority felt uncomfortable with the random choices. At the same time, we started welcoming a large number of new users from China, many of whom don’t speak English. To make Feem more inclusive and universal, we switched our default naming strategy from English words to random numbers—for example: 100 007, 958 322, and so on.

My Approach: I built a local-only communication platform rather than just a file transfer utility:

  • Native Gallery Components: iOS/Android interfaces that handle thousands of photos efficiently using our thumbnail pipeline
  • Integrated Chat: Text messaging alongside file sharing via our message dispatcher system for links, snippets of code etc.
  • Content-Centric Design: Users select by content type, not file system location
  • APK Distribution: Android users frequently share applications directly between devices.

The result feels more like WhatsApp than traditional file managers—because that's how people actually want to communicate.

3.5 Thumbnail Generation Pipeline

Real-time thumbnail generation for millions of photos requires careful memory and threading management, plus platform-specific OS integration:

class ThumbnailEngine {
    // LRU cache for thumbnails (memory-mapped)
    std::shared_ptr<LRUCache<std::string, ThumbnailData>> thumbnailCache;

    // Thread-safe thumbnail processing queue
    std::mutex processingMutex;
    std::queue<ThumbnailRequest> processingQueue;
    std::condition_variable processingCondition;

    // Platform-specific image processors
    #ifdef __APPLE__
    QuickLookProcessor quicklook;     // macOS/iOS native thumbnails
    #endif
    #ifdef _WIN32
    WindowsThumbnailProvider winThumb; // Windows thumbnail cache
    #endif
    #ifdef __ANDROID__
    AndroidMediaProcessor mediaProc;   // Android MediaMetadataRetriever
    #endif

    ImageProcessor fallbackProcessor;  // Custom implementation
    ...
    ...
}

This low-level systems programming approach delivers the performance needed for smooth user experience even with massive file collections.

3.6 The OS Upgrade Arms Race

Major OSes introduce new restrictions every year:

  • File Access: Increasing sandboxing limits what applications can touch
  • Network Access: Location permissions required just to show WiFi network names
  • Background Processing: Mobile OS updates break transfer reliability
  • Privacy Controls: New photo access models change fundamental APIs

The technical debt from OS changes often exceeds feature development effort. Each "security improvement" requires architectural evolution on our end.

3.7 Technical Lessons Learned

  1. Abstract Early: Unified cross-platform engines will prevent technical debt accumulation
  2. Stream Everything: File-as-object models break on modern platforms.
  3. Network Defensively: Always assume connection failures and implement resumption
  4. Platform Native Where It Matters: UI performance and system integration can't be abstracted away
  5. Privacy by Design: Local-first isn't just about bandwidth—it's about control

4. Impact: Traction and Validation

2M+ Downloads

Market Response:

  • 2M+ downloads across major platforms
  • Countless glowing reviews and user-made demo videos
  • Real-world impact in places where offline access matters most
  • Trusted by people who value privacy and security
  • Paying customers, including businesses using Feem in the field
  • Use cases beyond bandwidth-constrained regions — like construction field agents in the US

Feem has quietly become a lifeline for both bandwidth-starved communities and privacy-sensitive users worldwide.

Real-World Applications:

  • Construction teams sharing blueprints without internet
  • Medical professionals transferring patient data securely
  • Creative professionals moving large media files
  • Teachers sharing educational video content with students in the classroom.
  • International users avoiding government internet restrictions

5. The Path Forward: Beyond File Sharing

Feem v5 represents a complete architectural rebuild addressing years of OS evolution and restriction creep.

But offline file sharing is just step one in a much larger vision.

5.1 Idea: The African Edge Computing Revolution

Feem Box

Traditional computing relies on client-server models with centralized points of control—and failure. When sanctions hit or infrastructure fails, entire regions go dark.

By combining Feem's proven offline transfer capabilities with execution protocols (inspired by UUCP and NNCP), we could pioneer a new paradigm: African-born edge-to-edge computing.

Imagine sending not just files, but computational tasks across the network:

  • Distributed AI: Train models on your device or across multiple Feem Boxes
  • Content Processing: Video transcoding, image analysis, document generation
  • Data Analysis: Process datasets where they reside, not where servers exist
  • Application Deployment: Run services across the mesh without central coordination
  • Offline Payments: Process wallet balances and financial transactions entirely offline between devices, with settlement occurring opportunistically when any device in the mesh reaches banking infrastructure
  • Decentralized Identity: No single entity should decide who you are or what you're entitled to.

This isn't just about avoiding cloud dependency—it's about creating computing infrastructure owned by its users.

5.2 Technical Foundation For The Idea

Feem’s existing technology stack lays the groundwork for this vision:

  • Cross-platform engine: battle-tested on mobile and desktop, ready to scale into dedicated hardware.
  • Resilient networking core: built to handle peer-to-peer and mesh synchronization, extendable with store-and-forward protocols.
  • Flexible file abstraction: designed for file transfers, adaptable to carrying computational payloads.
  • Hardened security model: ensures confidentiality and integrity in distributed processing.
  • Proven in the field: optimized under real-world African network conditions where resilience matters most.

Conclusion

When you can’t rely on Silicon Valley’s infrastructure—or funding—you’re forced to innovate differently. Constraints breed creativity.

Today, we’ve built Feem, the best offline file transfer tool. Our unique engineering and careful implementation have made it a joy for millions of users, not just in Africa, but around the world.

Tomorrow, given the opportunity, we aim to lay the foundation for a new kind of internet—one built on edge-to-edge computing.

Share this project:

Updates