Tim, The test flight store was having issues. It looks ok but I can't test it fully as it gives me more access. Can you try it again now? If it still fails, send me the email you log in to Apple with, and I will add it explicitly. It's supposed to be an open test. But the app connect is very squirrely. All the development is scriptable. But as soon as it goes to the store it is all clicks and buttons.
----- Original message ----- From: Tim Mackinnon <[email protected]> To: Any question about pharo is welcome <[email protected]> Cc: Aaron Wohl <[email protected]> Subject: Re: [Pharo-users] iPad Pharo test release Date: Wednesday, February 25, 2026 8:52 AM Hi Aaron - I was curious what you had done and tried the TestFlight angle but it says you're beta isn't accepting any testers (not sure if thats a setting you control - but just an FYI). Like you - sometimes it is nice to just travel with an iPad and be able to try out random ideas - so we interested in how slow it practically is. Tim On Wed, 25 Feb 2026, at 1:19 PM, Aaron Wohl via Pharo-users wrote: > Pharo 13 for iPad in the test Apple Store (open in the Apple TestFlight app); > Phone or Mac https://testflight.apple.com/join/kGmPQFr9 > Due to Apple’s no JIT, it's not snappy. But maybe it's still useful? > Source https://github.com/avwohl/iospharo about 100K lines of new source code. > > This is my first venture into using Pharo. I could use advice on where > this project fits in Pharo/Smalltalk land. In the early 80s, I used > the Xerox Parc Alto at Carnegie Mellon to run Smalltalk. I got laid > off, went on a cruise, sat down in a beach chair with LEARN PHARO and > an iPad. But, no Pharo for iPad. So I did the natural thing and told > Claude Code to port Pharo to iPad. 54 days and 1347 commits later, out > popped a usable iPad app. I do have a background in compilers, working > on the Production Quality Compiler project at CMU in the early 1980s, > mostly on lexers. But I didn’t write any code for this. I mostly told > CLAUDE a few times a day stop doing workarounds, do what the real VM > does, and that’s a workaround. CLAUDE would never have succeeded I > think if I hadn’t started insisting a focus on getting the test suite > to pass rather than the app to work. > > The main snag using the real VM was encoding the encoding of type info > in the high bits of pointers for immediate types. It seemed simple to > me to shift the type info to the low 3 bits. But Claude could not get > the real VM to stop looking in the high bits; perhaps I should have > pushed harder on that. But I had always heard how easy it was to port > Smalltalk, so I just went with a new VM with the type info in the low > bits. Loading a standard image translates the addresses. > The other issue was that Apple forbids JIT on iPad. So this new VM has > no JIT. > Issues: > - Should this be a separate VM? Should I push harder on getting the > standard VM to work with type info in the low bits and no JIT? Even if > that would be better, is it worth the bother now that this works? > > - I don’t want to suck up the PharoSmalltalk name in the Apple stores > if it causes offense. I can call it VibeTalk or something to leave the > name free for a hand-coded version. Or move off the name if a real > contender ever shows. > > - Without JIT, is it too slow to bother releasing? Is there some other > optimization that could bridge the gap if it is too slow? > > - Are there any users who can give the iPad version a really good > workout in real work? The VM passes the test suite. But it just > started working on the iPad today. There will be UI issues. > > - On the iphone the menu bar is cut off, and the welcome window is > mostly off the screen. The menu bar layout is in the image, not the > VM. I am not sure the VM should work around it. Should these be fixed > in the image to have a multi-line menu bar as needed, and reshape > initial window layouts on phones? If so is anyone willing to do the > Smalltalk side or help me do it (I have written mostly other languages)
