Learning to Code on a Phone: What Actually Broke, and What Fixed It

The part people get wrong about phone development

When people hear that someone learned to code on a phone, they usually picture the discomfort: the small screen, the on-screen keyboard, the missing shortcuts. Those are real, and they are also not the problem.

The actual wall is installation. Writing Python on a phone is easy. Getting the libraries you want to install and run is where the whole thing stops.

I started learning and developing software on an Android phone, primarily using Termux, rather than starting with an expensive computer setup. What follows is what actually broke and what eventually got past it. I am not going to tell you it was straightforward, because it was not.

Where it stalled: dependencies

Early on I kept running into dependency and installation problems while trying to build the tools I needed. Not syntax errors, not logic bugs — the code was not the obstacle. Package installation was.

The stack I eventually worked with gives a sense of the shape of it: NumPy, pandas, pandas-ta, scikit-learn, WebSocket and API libraries, and the other dependencies an automated trading system needs. The numerical and data-analysis side was one of the hardest parts of developing on the phone, because several of those packages carry native or compiled dependencies that are far more troublesome to install in a mobile Termux environment than on a normal desktop Linux system.

It also compounded. I needed libraries for technical indicators, for machine learning, and for talking to trading APIs, so the dependency chain grew more complicated as the bot got more sophisticated. Each new capability was another package, and another chance for something underneath it to refuse to build.

I am not going to name the one package that first stopped me, because I cannot verify that from my old setup and history, and it would be easy to pick a plausible one after the fact. What I remember clearly is the category of problem: dependency installation and heavier Python packages were a major obstacle. That is specifically what sent me looking for a different environment.

The detour: trying Ubuntu on the phone

Because of those limitations, I moved to an Ubuntu environment on the phone to see if it would make development and package installation easier.

This is worth being honest about, because it is the step that usually gets edited out of these stories. The obvious move when your environment fights you is to replace the environment. So I did.

It was not the answer. I eventually went back to Termux — not because Ubuntu failed outright, but because I had worked out a better way to handle the actual problem, and once that was solved the reason for the detour disappeared.

What changed things: isolating the project with venv

The important discovery for me was that using a Python virtual environment — venv — inside Termux gave me a much better way to isolate the project and manage its dependencies. That is what let me carry on building the trading system directly on the phone instead of abandoning it because of the limitations of the mobile environment.

I want to be precise about what that did and did not do, because this is the point where advice like this usually overstates itself.

A virtual environment does not make heavy packages install. It is not a workaround for a missing prebuilt wheel, and it does not remove the need to compile something that has to be compiled. Individual packages can still have their own installation requirements, and some of them still will.

What it changed was control. The project's dependencies became isolated from everything else on the system, which made the environment something I could reason about and manage rather than something that drifted and broke in ways I could not trace. Once the environment stopped being the moving part, the remaining problems were individual package problems — and an individual package problem is solvable in a way that a generally unstable environment is not.

That is a smaller claim than 'venv fixed it'. It is also the honest one, and it was enough to keep the project alive.

Why installing anything on Termux is genuinely hard

It is worth understanding why this is difficult, because it is not a failure on your part and it is not Termux being badly built.

Most Python packages that contain compiled C code ship as prebuilt wheels on PyPI, and those wheels are built for standard Linux distributions. Termux runs on Android, which uses a different C library, so those prebuilt wheels do not match. Instead of dropping in a ready-made binary, pip falls back to compiling the package from source on the device — which needs a working toolchain and every build dependency present, and which is slow on a phone.

This is why the failures cluster around exactly the libraries you most want. NumPy has historically failed on Termux with an error about required math functions being unavailable, with the widely shared workaround being to set the MATHLIB environment variable before installing. SciPy needs BLAS and LAPACK present before it will build at all, and one person who got it working reported the build alone taking more than fifteen minutes.

Two things worth knowing that are easy to miss. Termux's own package manager carries prebuilt versions of some of these libraries — installing numpy through pkg rather than pip sidesteps the compilation entirely, and on a well-known Stack Overflow thread that single distinction between pkg and pip was the fix. The Termux User Repository also provides additional prebuilt packages and a package index you can point pip at directly.

None of that is obvious when you are starting out. You get an error that looks like your fault, and nothing tells you the wheel simply does not exist for your platform.

Why I kept going

I did not persist because I had unusual discipline. I persisted because I wanted something specific.

The whole process was driven by wanting to build trading software. I kept experimenting with different Python libraries and development tools because I wanted to build my own automated trading systems rather than simply use someone else's.

That matters more than any technique in this article. A dependency error is a wall if you are learning to code in the abstract. It is a puzzle if it is standing between you and something you actually want to exist. Same error, completely different response.

The environment problems did not stop being annoying. They stopped being reasons to quit.

What the setup became

The same phone-based development setup eventually became capable of supporting much more serious projects: Python trading bots, API integrations, automation and websites.

I want to be careful here, because this is where this kind of story usually inflates. I am not claiming phone development is as comfortable as a laptop, that it is the right choice if you have an alternative, or that it made anything faster. It did not. Every one of those constraints was real and none of them disappeared.

What I am saying is narrower and, I think, more useful: the device was not the thing that decided whether the learning happened.

If you are trying this

Assume installation is the hard part, not writing code. Budget your patience accordingly.

Use a virtual environment early. It will not make a stubborn package install, but it gives you an environment you can control and reason about, and it stops one project's dependencies from breaking another's. For me that was the difference between continuing and stopping.

Try the platform's package manager before pip when a library refuses to build. On Termux that means pkg, and for several of the heavy scientific libraries it is the difference between working and not.

Expect the numerical and data-analysis packages to be the difficult ones. That is where the compiled dependencies live.

When an install fails, search the exact error together with Termux rather than alone. These failures are platform-specific and extremely common, and someone has almost always hit the same one.

And do not switch environments at the first serious obstacle. I did, and it cost me a detour. Sometimes the environment really is the problem. More often the problem travels with you.