I can't agree to that. First of all, the iPhone has huge display resolution similar to an expensive Android phone. Secondly, most Android phones have much more powerful CPU then the iPhone. So I guess it even runs more fluent then on the iDevices. But its only a guess, at the moment I don't plan on porting to Android anyway (even it won't be that hard once there is a working mobile version).
EDIT: @DrSuperGood: Just compared the specs of a common Android phablet (Samsung Galaxy S4) with iPad tablet: Galaxy S4 has 2/3 lower display resolution but every CPU core is around 50% faster then iPad one. So since it works on iPad it should work on Android phablet too, don't worry.
So you are telling me that a 1.4 GHz ARMv7 dual core is sufficient to render a 2048×1536 (3,145,728) pixel display of pak128 at full frame rate? Wow and here I am with a 2.67 GHz quad core i7 processor powering a 1680*1050 display which drops a few frames every time I change underground view height in pak128.
As I mentioned before, it will likely perform acceptably on low dpi display devices. My concern is with the high dpi display devices since they often use the same CPU as the low density display devices as they rely on a better GPU instead to fill the larger display (which makes sense if the game did not software render everything). Also the devices are not designed to have their CPU running at full clock rate for extended periods so you will find very poor battery life running the game and the possibility of some devices starting to perform badly after a while of use to prevent overheating.
As such for both scaling and to better support mobile HCI elements I would strongly advise rendering to an intermediate display buffer and then using the GPU to scale that up to whatever the display resolution is. This buffer can probably be mixed with existing mobile UI elements pretty efficiently unlike the SDL which seems to dominate the display to some extent (simutrans does not let me alt+tab when in full screen and unresponsive). It also allows you some form of power management capabilities since you can adjust the work load of the processor by changing the buffer size (smaller buffer size will mean less CPU work, native buffer size will produce best quality graphics).
I have tried several approaches to adding GPU acceleration to Simutrans, but every one has failed so far. Simutrans architecture is very tied to the way it renders on the CPU. My first attempt, which was basically replacing all functions that did rendering in the CPU with functions that sent commands to the GPU to do the same operation, was even slower that rendering on the CPU. The reason was that the size of all the commands sent to the GPU exceeded the size of the framebuffer, at times by many orders of magnitude. To get performance, one needs to have big static batches ready for the GPU to execute, and only regenerate them when something has changed. But if vehicles are included, the batches will change all the time. So vehicles need to be outside the static batches, but this means that Simutrans can no longer use painter's algorithm for depth sorting. The biggest problem is figuring out that something has changed, so that the corresponding batches are invalidated. And then there is coming up with pixel shaders that can replicate all the color tricks in Simutrans' rendering code, and an efficient texture manager.
On what platforms did you try? As I stated, mobile devices probably act a lot like game consoles as far as GPU interaction goes. Where as on the PC it is very expensive to send stuff between GPU and CPU, in game consoles doing this is virtually free as there is no physical chip I/O and no PCI-E buss to transfer through. In theory swapping a buffer between GPU and CPU is nothing more than flushing caches and passing a pointer since they share the same physical memory, however if the driver implements this so is another question. In standard discrete graphics PCs this is impossible since all buffers have to be copied between main memory and graphic memory which itself is a very expensive and time consuming operation.
The key importance is to get GPU rendering in a way that saves CPU time. If it takes excessive GPU time it is less of a problem.
Looking at some files I do agree that simutrans does appear to excessively couple graphics with game state. I am not sure why that design decision was made as usually it is the practice to have a separate graphic system from the game state that communicate using some form of message passing or state mirror.