I remember there was a publisher in Play Store who had very small apps like single digit kb flashlight, sudoku, calender, etc. I can't find them now. Those apps were really small all within <200kb

That reminds me of one reason I got out of mobile app development, totally forgot about until now

Often times the hiring managers wanted to see something more akin to a portfolio, like an art project, for apps that many times didn’t exist anymore or have a production server up anymore

But the more arbitrary metric was trying to be sure that I worked on anything “big”

And the 8-12 megabyte package sizes - which I spent a lot of time optimizing with many competence inspiring techniques - would signal that the app or service or userbase wasn't big. Which had nothing to do with anything, could have hundreds of millions of downloads and users

In that space there is a huuuge incentive for bloatware

I continue to be puzzled by how much smaller apps are on Android, ex. Took me 9 tries, including ads, to find a thermometer app over 7 MB. I've worked on both platforms for years and yet don't really know why. Only guess is Android has a much richer tradition of vector art over bitmaps, and Swift libraries had to be compiled in for years until ABI stability enabled using dynamic linking to OS ones

The red flag for me is that they're all “free.”

Let me filter by apps that cost money, are ad free, and sometimes even: don’t have in-app purchases.

Aurora Store can at least filter by paid/IAP/has ads

> 150 megabyte thermometer app

Does such a thing really exist? Or are you just making a point?

How would this feature handle an update that increases the file size? What about apps that download assets after you install them?

Doesn't fstore have a filter for that?

Why, what's wrong with 172MB calculator app?

I have always felt there is something fascinating going on behind Flappy Birds' infamous difficulty curve that warrants deeper study.

On the one hand, there is no actual progression or ramping of difficulty in the game itself. The difficulty level remains the same whether your current score is 0 or 10 or 100. But every new highscore represents a new summit that the player has to scale. The first and maybe the most frustrating summit to scale is scoring a single point. To get your score into the double digits, the player has to have basic mastery of the core mechanics - including the precise physics, and timings- and learn how to handle a certain number of scenarios. The obstacles on the path to triple-digit territory and beyond seem almost self-imposed. The fear and tension as you approach your own highscore is the biggest impediment to breaking your highscore. Once you break that highscore - the hand tremors magically disappear the next time you approach it, only for it to re-appear as you near your new highscore.

All this, when the basic concept of the gameplay is deceptively simple. Like i said, there are many layers to unpack for someone who is willing to look into it.

"It is surmised that conditioning is enforced via several cogni- tive biases that trick a player into expecting euphoria (liking- pathway), when instead frustration is yielded – with condi- tioning being iterated to a point that the player is motivated to interact with the game on a foremost instinctual level. We posit that these stimulations of the wanting-pathway may lead to players interacting with the game not only with- out actually liking it, but also without knowing why they are interacting with the game. Indeed, this calls for drawing another parallel between drug addiction, and play behaviour in which liking may be barely exhibited (cf. [16, 38, 40])."

Given that background, the odds you've never seen this are exceedingly low.

Nonetheless, and for the benefit of the Lucky 10,000, I must present: QWOP.

https://www.foddy.net/Athletics.html

As an expert in Flappy Bird I Will tell it's because people love to approximate polynomials...

Thank you for sharing, great work!

A student of mine had an assignment to write a game using SFML, they wrote a FlappyBird clone and it was like a few hundred lines of code. It's not a very complex program to write. To be honest, I think 4k is too much :)

A shame that 4k loc compiles to over 100k of binary size.

Also an assessment of speed gains would be nice.

The reason you have Java glue instead of C glue in most cases is that Java's is easier to write. Whatever you do, you need a Activity instance to run, and while you can create one from C, it requires a lot of boilerplate that is mostly taken care of by inheritance in Java. Here's how it's done in plain C: https://github.com/VadimBoev/FlappyBird/blob/master/FlappyBi... https://github.com/VadimBoev/FlappyBird/blob/master/FlappyBi...

It was also made to work on exactly one hardware specification, with no operating system to speak of. This flappy bird clone works on an immeasurable number of devices, with varying hardware AND software configurations!

That came to mind for me too, but unfortunately the name has already been taken by a few clones; the most notable being a trivial reskin that uses a floppy disk icon instead of a bird.

here in argentina everyone calls it 'floppy beard'. and of course 'angry birds' is 'ongry beards'

Yes, raylib does support android. I have a slightly incomplete build script I use for my raylib projects (obviously you need to take better care of signing, you probably want to build for other targets besides aarch64, your SDK is probably not installed in /home/denis, and I'm not sure whether I'm adding .so files to apk in a way modern android prefers, but it still works).

https://gist.github.com/deniska/f1ee73e18e1444eb724c01f933b6...

There's a Flappy Bird clone for the GameBoy, in the form of a 32kB ROM. [0][1][2]

This isn't to downplay this Android-based project though. They aren't claiming to have written the most compact Flappy Bird clone.

[0] https://laroldsjubilantjunkyard.itch.io/flappy-bird-gameboy/...

[1] https://laroldsjubilantjunkyard.itch.io/flappy-bird-gameboy

[2] https://www.youtube.com/watch?v=m839Vg_qXzM

I'm honestly surprised at the 100k figure. In my mind it should be possible go far lower. 10k sounds vaguely realistic.

Nothing special. Many inconsistencies, e.g. inconsistent variable naming (mixes snake camelCase and PascalCase). What kind of codebases are you looking at? I have seen way better ones. https://git.zx2c4.com has better. OpenBSD is great, too.

Same, would like to see the same but implemented in Rust

Do you still accept more optimizations? :-) I believe there are tons of mechanical substitutions that can be made there, for example `i%17?r+=z:r+='|\n|'+z` should simplify into `r+=i%17?z:'|\n|'+z`.

If constrained by size of result rather source you get sizecoding, a generalization of demoscene.

I totally support this!

Coincidentally I wrote a small 2048-inspired game just recently, it's under 13 KiB (zipped; the "real" file is about 30 KiB): https://js13kgames.com/2024/games/king-thirteen

If you're interested to check it out, please tell me what you think :)

I got a GOTY 2023 for my game YOYOZO which is just 39KB and includes custom physics, online high scores, two music tracks, and more. https://news.ycombinator.com/item?id=38372936

>pac man on the atari or snes is maybe less than 100kb

Off by an order of magnitude! Pac-man sizes:

    4K: Atari 2600 (it's bad)
    8K: Atari 800
    16K: Atari 800 Ms. Pac-Man
    24K: Original arcade machine (Z80)

You'll love Desert Golfing then.

Animal Well is 33 MB and is absolutely great

The game I like most is a multiplayer immersive reality game in 0 bytes called frogger, where I'm the frog.

Beat that! ;)

I made a sub-100k Android app once (I am now banned from the Play Store, and I should be lucky they didn't delete my Gmail account too) and every time I opened the IDE (Android Studio at the time) it would automatically add a Google "support library" to the project that Google obviously wanted to force me to use. If I forgot to remove it and built the app, it would be closer to 10MB. So that was the minimum size of almost every Android app at the time.

Most Android apps are huge because they bundle tons of assets just to accommodate the “initial experience of the user”. Also, using bloat libraries and frameworks (any shipped by Google), increase the apk size.

Nowadays Google offers a solution for this problem called app bundling. It’s especially good if you build a mono app that behaves differently in certain regions. Instead of delivering a raw apk, you deliver a region specific app bundle.

Android Studio allows you to debug Java, C/C++ or dual Java and C/C++ apps.

https://developer.android.com/studio/debug

Possibly through Termux... Surely for shell commands, I would say; I am not sure about hooking the debugger to a package

On a technicality, yes, but I think most developers who use it do so because of the large collection of React-style user interface components which are built into it. Now that Jetpack Compose exists (which allows for traditional Java-based widgets to be used in a 'reactive' way), personally I don't see any reason to use Flutter. That 'drawing directly' aspect puts Flutter apps several years behind in terms of performance, accessibility and reliability, since pretty much everything in the Android API needs to be reimplemented in Dart.

Seems this was fixed in https://github.com/VadimBoev/FlappyBird/commit/f57a3ec90078b... by forcing the gameloop to be 60fps.

It's a simple solution, but does mean that things are effectively capped at 60fps. The techniques in https://gafferongames.com/post/fix_your_timestep/ could be used to properly allow variable fps while maintaining constant physics speed.

I'm not sure if this is a joke or not, but there's no actual graphics in this besides a yellow ball and green rectangles, while the OP game has actual textured pipes, a textured floor, a background scene. The score counter looks to use a basic system or browser font, while the OP game has a custom font. The OP game has also high score tracking, sharing, a proper main screen instead of just dropping you into gameplay.

That was a 20 megabyte page load for me even with all the ad cruft blocked...to load a game in a browser, which is already the most batteries-included application platform I can think of.

nice! but how big is the .apk?