It's also not just apps from this repo, adding my own apps to ./wasp-os/wasp/apps and then building from scratch gives the same result, same for adding it to ./wasp-os/apps

Update: adding the folder itself and then file into it using eval to the watch makes it work, but isnt ideal.

Why isn't it ideal? What do you suggest? I think it's mostly just a documentation problem, and #392 fixes that. #403 instead makes it possible to customize the image itself, do you think that would be better?

Why isn't it ideal? What do you suggest? I think it's mostly just a documentation problem, and #392 fixes that. #403 instead makes it possible to customize the image itself, do you think that would be better?

Well why doesnt it check for the files in the main 'flash' dir instead, or just generate the 'apps' automatically

#392 ye ik about uploading as .mpy and then adding a line to main.py to upload it to ram, but i really dont want that.

#403 same day as this post i found out by looking at the source how to add apps to the binary through the manifest file and aoftware.py, tho #403 still seems like a great tool.

It only checks the app dir because the simulator and the os on the watch itself both share the same code. From the simulator's perspective that is where the apps should be. I agree it would be more user friendly if the dir was created automatically and I think that is what should be happening when you upload via wasptool. If you look at the upload methods near the end of the wasptool file there is code to do just that ( lines 313 and 355 ). But I can confirm that it does not seem to work for me either.

Hopefully #403 will be adopted and that will make flash apps less necessary. In my experience for an app of any real size to work it needs to be frozen into the firmware. Even loading a small .mpy from flash uses most of the system's ram.

Hopefully #403 will be adopted and that will make flash apps less necessary. In my experience for an app of any real size to work it needs to be frozen into the firmware. Even loading a small .mpy from flash uses most of the system's ram.

#403 has been adopted and working well for some time now - thanks!

As you say, "for an app of any real size to work it needs to be frozen into the firmware. Even loading a small .mpy from flash uses most of the system's ram.". The logical conclusion is that we have to look at RAM usage before putting any more effort into loading mpy from /flash. I see about 24448 bytes free in safe mode, but boot normally and I have about 8176 bytes free. If we chose to change things so that there is more memory free on normal boot then (and only then) does it make sense to be loading from /flash (SPI). If I get the time I'd love to find out where the memory goes.