Last Updated on February 15, 2024
So the calculator project. Heh. Things were going so smoothly. I’d finished it within a span of a few days. Found a couple nice fonts, added a fun little Matrix like background. The buttons and display were looking nice. The buttons and display were looking nice… right?
A Tale of Two Phones
Wrong. Well, partially wrong. As an Android and PC user, all my tests were solid. This is essentially what my calculator looked like on every browser on my laptop and phones at that point:
Not a pixel out of place. But then I sent it to a friend to test on his iOS device and the bloody thing looked like this:
What on god’s green earth?? Okay… cool. I played around with the sizing of each of my desktop browsers to see if I could replicate the issue. Nothing in Firefox. In Chrome, however, resizing below a certain threshold did cause issues, but only at sizes much smaller than your average smartphone. So I did a bit of research to see if I could find a browser that could more accurately simulate this issue.
Webkit Browsers for Linux?
As luck would have it, Epiphany switched their browser engine over to an opensource version of webkit — software that iOS browsers are based on. I installed the browser and launched the calculator app. After scaling the browser down to the size of a phone, I found that the issues were similar, but not the same. That was fine, for now. I had enough visual cues to diagnose problems and test solutions.
One of the issues was that the header and footer were overflowing their own sections and pushing buttons way out of bounds. Well, the header pushing things around. The footer was just hanging out doing non-footer things. Setting a margin of 0 on both of those was enough to keep things from being in areas of the page they weren’t supposed to be in.
In the calculator itself, I had to change the buttons and display from percentage units to fixed units, because for whatever reason, the smaller versions of webkit browsers were allergic to percentages. Then in a media query, I could scale the display, buttons, and text down to a percentage of their original sizes. Easy peasy! Once I got that figured out, it looked great on Epiphany, great on Firefox, great on my Chrome, and great on my phone. I expected it to look great on my friends phone, too…
“Webkit” Browsers for Who??
I asked my friend to test the app, expecting it look as it did in all my tests. Well… this is what he sent me:
I mean, it looked better, but there was still an overflow issue. My friend said, “It’s fiiiiine” and that I should just leave it. But he knows me better than that and if you’ve read anything else on this site, before, you probably do, too. And this is where the side quest began.
The Hunt for an iOS… Simulator? Emulator?
Typically when I doing tests I use Screenfly. It essentially does what you can do with a browser console or even a simple zoom. To me, though, it feels a bit more convenient, for reasons I may discuss in a separate post. The issue with Screenfly, though, is that it simulates different device sizes but not device behavior. And that simply would not do.
At my old job, we used BrowserStack. It’s an excellent service and I was able to get a few free uses out of it, but there were a couple of issues. One, I did not want to pay for it, and two, I needed something that worked offline. (I believe BrowserStack has something where you can use its service offline, but I admittedly didn’t have the patience to figure that out at that moment.)
This is actually what led me to discover the Epiphany browser, but as the previous section demonstrates, the Epiphany browser could only do so much. Remember when I said that the issues on Epiphany were similar but not the same? Yeah. That was no longer something I could ignore. I needed something that could emulate the behavior of an iPhone, not just simulate it. Before this project, I didn’t even realize those things were different.
In case you didn’t know, a simulator is like an uncanny valley clone of something. Its behavior is close enough to the real thing to be useful in many cases, but it’s not an accurate enough copy to truly mimic the real thing. An emulator, on the other hand, actually presents as the real thing because it’s not just mimicking outward behavior, but is actually based on the underlying hardware and software of the system it is representing. This makes emulators a heck of a lot better for testing and diagnosing device specific behavior that can’t be replicated in other environments.
The Search Continues
Epiphany helped me with the initial iOS problem, but it could only carry me so far. And since I’d already used up the free BrowserStacktests that were relevant to my specific issue and wanted an offline solution anyway, I had to keep searching.
This led me to PlayWright, another really excellent (and opensource!) solution. It’s an excellent choice for web devs who don’t want to have 50 billion browsers on their desktop and need a way to test mobile browsers without having to pull things up on their phone. However, it was still only a simulator. So that ended up being a no-go as well.
In my search, I found something about a guy who was able to create a successful emulation of the first iPhone. That was cool, and in the right ballpark, but not exactly ideal for resolving issues on modern Apple devices.
Then I found Darling. It was advertised as being the MacOS version of Wine (Linux adaptation of Windows). The kicker, however, was that it had limited graphics support. By this point in my search, I realized that my best bet at replicating the iPhone bug was to find a way to use the graphical version of Xcode, Apple’s version of VSCode. I could use the cli version of Xcode with Darling, but that was it. That was not going to work for me. Something I didn’t realize until after I downloaded it. I knew there was limited graphical support, but I saw Xcode and just assumed (or rather naively hoped) that included the graphical version. The docs said otherwise. Remember kids, read the documentation. It’ll save you a lot of time down the road.
The Holy Grail?
Then I found it… Docker-OSX. The virtual machine version of MacOS that could actually run Xcode, with a screenshot that included the graphical version of Xcode. O-M-Fucking-G, how lucky could I be?! I read the instructions to download and install one of the versions. The installation took hours to run, so I had to do other things in the while I waited. I created an new apple account, because I did not remember the one I used for iTunes over a decade ago. Then, I downloaded Xcode and tried to run the iOS simulator. Insufficient RAM. … 😮💨 Mkay. I nuked the Docker container and ran the installation again. Using the installation wait time to look up why this would be an issue if the default RAM was 4GB and that’s how much Xcode said it needed. Maybe I did something wrong.
I found a guide on the internet and used that to install Xcode. Insufficient RAM. I reinstalled it again. Several times, using the same set of instructions. Looking back, I think I might of have been delirious or something. Like, who in their right mind is going to keep doing the same bloody thing over and over again, expecting different results? Oh wait…
I eventually realized that some of the RAM was being reserved to run the OS, itself. As a Linux, user, I really should have known this already, but I had been trying to find a way to locally test this issue for so long as this point, that critical thinking had essentially been replaced by stubbornly irritated decision making. I honestly probably needed to take a break and do something else. I did not. Don’t be like me. Take breaks. Breaks are fundamental. Like reading…
Docker Tings
I looked into a way to increase the memory. I downloaded Docker Desktop for the first time to try increase the memory because the that was the first solution I’d found. That led to an “all my containers and images disappeared” scare. Thankfully, the actual problem wasn’t that my containers and images were gone. They just weren’t available to the non-root user anymore. That was frustrating, but at least nothing got deleted. The problem fixed itself, eventually.
But before I realized that, I tried to create a docker-compose file to persistently store the data somewhere I could reach it, like I’d done for some other Docker projects. I also wanted to use it to define the memory of the container (the solution using Docker Desktop did not work). I was pleasantly surprised that I successfully built the container. Still, the memory had not changed. Welp, back to the search engine I went!
Reading Is What, Kids? … Fundamental!
I found a forum post where someone posted about the exact issue I was having. And they had a solution! And a link to the original repository! All I needed to adjust the internal memory was a simple flag in the shell script! What fun!
Guess where that information was in the repository… It was further down in the README where I’d gotten instructions to build the Docker-OSX container in the first place. I literally just needed to scroll down and read and would have been able to correct the issue by at least the second attempt if I had just read it. Just a little further down. That’s all. 😑
The Light at the End of the Tunnel
On the bright side, I’d finally found my way there, and after a couple of adjustments to the memory, I’d gotten myself a running virtual mac with a functioning if mind numbingly slow graphical Xcode with an iOS simulator that actually replicated what was happening on my friend’s iPhone. I combed through my code and I compared the results of what I was seeing on this virtual iPhone to what I was seeing everywhere else. My code was fine. I finally took my ass to ChatGPT and asked what the hell was going on. Wanna guess what the issue was..?
PADDING! IT WAS FUCKING PADDING!! OHMYFUCKINGGOD!!! All that work for FUCKING PADDING!! 😤
A Tiny Little Rant About Apple
Lol please excuse me. It’s been weeks since I figured that out and I’m still frustrated about it. Apple puts extra padding on their buttons and in smaller viewports, if the container is small enough, it throws the contents off center. All that work and the only thing I needed to do was set the padding to 0 for smaller devices.
On one hand, I finally have a way to natively test apple devices without having to bother my friend every five minutes. But on the other hand, it really should not be this difficult for non-Apple device using developers to create a pleasing browser or app experience for Apple end users. I get that they want everyone to buy into their ecosystem to increase profits, but I must admit that this experience has probably pushed me further away from Apple, not closer.
And apparently, this is not a unique experience. Even now, as of the writing of this post, Apple’s got some testy relationships with developers even with their new flagship Apple Vision Pro. As a non-VR user (and yes, I know Apple says it’s not VR, but come on… We all know better, right?), that device looks super cool and is something I genuinely would like to try. But as a developer, I should not need to buy a device just to make sure some small things are working properly on a browser. A browser! I can see that being a necessity for native apps, but browsers? Come on Apple.
Gratitude
But that’s why things like BrowserStack and Docker-OSX exist, and I am seriously grateful for them. BrowserStack has been seriously helpful in the work environment and Docker-OSX is going to be my go to for personal projects for as long as it exists, even if I do eventually get an iPhone or sign up for BrowserStack.
Even though the process to find an emulator has been a rather challenging journey, I now know and have what I need to properly diagnose and solve any issues I might run into with Apple devices for as long those projects or projects like those exist. The developer community is the best! 😊