iPad Pharo test release
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)
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)
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 tim@testit.works
To: Any question about pharo is welcome pharo-users@lists.pharo.org
Cc: Aaron Wohl xphu@awohl.com
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)
Just an FYI - I've been talking to Aaron in the background to see how it looks - and it launches on my ipad pro (a pre mX version) and seems workable although we are looking at how you actually do stuff if you don't have a physical keyboard as thats still a bit awkward while Claude is working on other stuff (its pretty neat seeing how he just asks Claude to take my comments and figure out what to do - its like havind a maid running around behind you).
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)
I just thought it might be interesting to give a small update on the progress that Aaron (or Claude) has made getting an iOS Pharo working. It’s frankly damn amazing that feedback I’ve sent over to him is forwarded to Claude and a new build pops out sometimes minutes later. It’s still being tweaked but man it runs on my iPhone and IPad quite well (from my limited usage so far). Hats off to Aaron to pushing on this, it might have a deep impact on how efficiently this community can generate radical improvements.
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)
I have an iPad 6 (model A1893 if anyone cares).
Will Pharo run on that device?
How much storage do I need to install Pharo on this iPad?
(And TestFlight itself.)
I've never heard of the test store before; could the README in GitHub
be extended with instructions about how to install the beta?
If you had infinite time and I had money to pay for it ...
it would be nice to have a binding for Core Motion.
But having Pharo on the iPad? Huge thanks.
On Thu, 26 Feb 2026 at 02:19, Aaron Wohl via Pharo-users <
pharo-users@lists.pharo.org> 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)
The motion code is not released yet. Probably tomorrow
can you reasearch the earliest iPad and or iOS this will run on. a user writes ...
Here's the research summary:
iPad 6 (A1893) — Yes, it will work.
- iPad 6 has an A10 Fusion (arm64) and supports up to iPadOS 17
- Our deployment target is iOS/iPadOS 15.0, so it's well within range
- It won't get iPadOS 18+, but iPadOS 17 is fine for us
Minimum supported devices (iOS 15.0 deployment target):
iPads: iPad 5th gen (2017) and newer, iPad Air 2 (2014), iPad mini 4 (2015)
iPhones: iPhone 6s / 6s Plus (2015), iPhone SE 1st gen (2016)
Storage requirements:
-
- App itself (debug build): ~15 MB
-
- Pharo 13 image: ~56 MB
-
- Pharo sources file: ~43 MB
-
- Changes file: ~20 KB
-
- TestFlight app: ~30 MB (from App Store)
Total: ~150 MB for everything
So even a 32 GB iPad 6 has plenty of room.
Re: TestFlight instructions — that's a good idea for the README. Re: Core Motion binding — that would be a fun Pharo FFI
project (accelerometer, gyroscope, compass on iPad).
Want me to update the README with TestFlight install instructions?
...
Added the following:
| data | │
│ "Start motion updates" │
│ <primitive: 'primitiveMotionStart' module: 'CoreMotionPlugin'>. │
│ │
│ "Read latest sample — Float64Array of 13 elements" │
│ data := <primitive: 'primitiveMotionData' module: 'CoreMotionPlugin'>. │
│ "Elements: accelX,Y,Z (1-3), gyroX,Y,Z (4-6), magX,Y,Z (7-9), │
│ roll,pitch,yaw (10-12), timestamp (13)" │
│ │
│ "Stop updates" │
│ <primitive: 'primitiveMotionStop' module: 'CoreMotionPlugin'>. │
----- Original message -----
From: Richard O'Keefe raoknz@gmail.com
To: Any question about pharo is welcome pharo-users@lists.pharo.org
Cc: Aaron Wohl xphu@awohl.com
Subject: Re: [Pharo-users] iPad Pharo test release
Date: Sunday, March 01, 2026 7:10 PM
I have an iPad 6 (model A1893 if anyone cares).
Will Pharo run on that device?
How much storage do I need to install Pharo on this iPad?
(And TestFlight itself.)
I've never heard of the test store before; could the README in GitHub
be extended with instructions about how to install the beta?
If you had infinite time and I had money to pay for it ...
it would be nice to have a binding for Core Motion.
But having Pharo on the iPad? Huge thanks.
On Thu, 26 Feb 2026 at 02:19, Aaron Wohl via Pharo-users pharo-users@lists.pharo.org 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)
Its worth adding to this, to set expectations - I have been testing on an iPhone 13 pro (so a few years old) and an iPad Pro 2nd Gen (from about the same time period).
While the iPad has more CPU cores, the A15 bionic chip of the iPhone does run this better, and its a bit sluggish on the ipad and a bit nippier on the iPhone. If I change the Color Theme from the startup screen, both devices will pause for 15seconds or more while they process that - however things like code lookup or evaluating factorial, or dragging windows all are acceptable.
An iPad 6 is 30-70% slower than my iPad pro, so I suspect it will work but be quite laggy without the jitter. Still its a worth a shot.
I think that modern M series ipads will probably work quite well - and the lack of a jitter might not be a big impediment.
It worth a shot, and maybe Claude might spot some interesting optimisations - its kind of amazing how its churning through my feedback to Aaron so far.
Today its added useful toolbar icons and its starting to look like a viable part time coding environment - i'm quite stunned.
Tim
On Mon, 2 Mar 2026, at 12:53 AM, Aaron Wohl via Pharo-users wrote:
The motion code is not released yet. Probably tomorrow
can you reasearch the earliest iPad and or iOS this will run on. a user writes ...
Here's the research summary:
iPad 6 (A1893) — Yes, it will work.
- iPad 6 has an A10 Fusion (arm64) and supports up to iPadOS 17
- Our deployment target is iOS/iPadOS 15.0, so it's well within range
- It won't get iPadOS 18+, but iPadOS 17 is fine for us
Minimum supported devices (iOS 15.0 deployment target):
iPads: iPad 5th gen (2017) and newer, iPad Air 2 (2014), iPad mini 4 (2015)
iPhones: iPhone 6s / 6s Plus (2015), iPhone SE 1st gen (2016)
Storage requirements:
-
- App itself (debug build): ~15 MB
-
- Pharo 13 image: ~56 MB
-
- Pharo sources file: ~43 MB
-
- Changes file: ~20 KB
-
- TestFlight app: ~30 MB (from App Store)
Total: ~150 MB for everything
So even a 32 GB iPad 6 has plenty of room.
Re: TestFlight instructions — that's a good idea for the README. Re: Core Motion binding — that would be a fun Pharo FFI
project (accelerometer, gyroscope, compass on iPad).
Want me to update the README with TestFlight install instructions?
...
Added the following:
| data | │
│ "Start motion updates" │
│ <primitive: 'primitiveMotionStart' module: 'CoreMotionPlugin'>. │
│ │
│ "Read latest sample — Float64Array of 13 elements" │
│ data := <primitive: 'primitiveMotionData' module: 'CoreMotionPlugin'>. │
│ "Elements: accelX,Y,Z (1-3), gyroX,Y,Z (4-6), magX,Y,Z (7-9), │
│ roll,pitch,yaw (10-12), timestamp (13)" │
│ │
│ "Stop updates" │
│ <primitive: 'primitiveMotionStop' module: 'CoreMotionPlugin'>. │
----- Original message -----
From: Richard O'Keefe raoknz@gmail.com
To: Any question about pharo is welcome pharo-users@lists.pharo.org
Cc: Aaron Wohl xphu@awohl.com
Subject: Re: [Pharo-users] iPad Pharo test release
Date: Sunday, March 01, 2026 7:10 PM
I have an iPad 6 (model A1893 if anyone cares).
Will Pharo run on that device?
How much storage do I need to install Pharo on this iPad?
(And TestFlight itself.)
I've never heard of the test store before; could the README in GitHub
be extended with instructions about how to install the beta?
If you had infinite time and I had money to pay for it ...
it would be nice to have a binding for Core Motion.
But having Pharo on the iPad? Huge thanks.
On Thu, 26 Feb 2026 at 02:19, Aaron Wohl via Pharo-users pharo-users@lists.pharo.org 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)
Claude has a code review mode. One of the phases does performace improvements. Also, CLAUDE has done comparisons with the timing of the full test suite on the Mac standard vm vs our vm. Some digital math factorial functions were missing. But after that, it all seems to come down to the lack of JIT. It hurts a lot.
Claude suggested pre-compiling (at build time) all hotspots into C code. This would be part of a fake JIT. You could change the Smalltalk code, and it would invalidate the JIT and get slow. But only for that function. I suppose if you made a change to the Object, all JIT would be lost. But I haven't looked into it yet.
There was also a suggestion to have a serious Smalltalk group petition Apple for a workaround to the JIT ban. Originaly Apple banned all code that can write code. But I recently published a Z80 CP/M emulator, and Apple had no problem with that. Although they did hold up the Mac version half a month due to a zork1 copyright inquiry (but the iPad with zork1 was fine). So Apple can loosen up and still be squirrely at the same time.
----- Original message -----
From: Tim Mackinnon tim@testit.works
To: Any question about pharo is welcome pharo-users@lists.pharo.org, Richard O'Keefe raoknz@gmail.com
Cc: Aaron Wohl xphu@awohl.com
Subject: Re: [Pharo-users] Re: iPad Pharo test release
Date: Monday, March 02, 2026 5:21 AM
Its worth adding to this, to set expectations - I have been testing on an iPhone 13 pro (so a few years old) and an iPad Pro 2nd Gen (from about the same time period).
While the iPad has more CPU cores, the A15 bionic chip of the iPhone does run this better, and its a bit sluggish on the ipad and a bit nippier on the iPhone. If I change the Color Theme from the startup screen, both devices will pause for 15seconds or more while they process that - however things like code lookup or evaluating factorial, or dragging windows all are acceptable.
An iPad 6 is 30-70% slower than my iPad pro, so I suspect it will work but be quite laggy without the jitter. Still its a worth a shot.
I think that modern M series ipads will probably work quite well - and the lack of a jitter might not be a big impediment.
It worth a shot, and maybe Claude might spot some interesting optimisations - its kind of amazing how its churning through my feedback to Aaron so far.
Today its added useful toolbar icons and its starting to look like a viable part time coding environment - i'm quite stunned.
Tim
On Mon, 2 Mar 2026, at 12:53 AM, Aaron Wohl via Pharo-users wrote:
The motion code is not released yet. Probably tomorrow
can you reasearch the earliest iPad and or iOS this will run on. a user writes ...
Here's the research summary:
iPad 6 (A1893) — Yes, it will work.
- iPad 6 has an A10 Fusion (arm64) and supports up to iPadOS 17
- Our deployment target is iOS/iPadOS 15.0, so it's well within range
- It won't get iPadOS 18+, but iPadOS 17 is fine for us
Minimum supported devices (iOS 15.0 deployment target):
iPads: iPad 5th gen (2017) and newer, iPad Air 2 (2014), iPad mini 4 (2015)
iPhones: iPhone 6s / 6s Plus (2015), iPhone SE 1st gen (2016)
Storage requirements:
-
- App itself (debug build): ~15 MB
-
- Pharo 13 image: ~56 MB
-
- Pharo sources file: ~43 MB
-
- Changes file: ~20 KB
-
- TestFlight app: ~30 MB (from App Store)
Total: ~150 MB for everything
So even a 32 GB iPad 6 has plenty of room.
Re: TestFlight instructions — that's a good idea for the README. Re: Core Motion binding — that would be a fun Pharo FFI
project (accelerometer, gyroscope, compass on iPad).
Want me to update the README with TestFlight install instructions?
...
Added the following:
| data | │
│ "Start motion updates" │
│ <primitive: 'primitiveMotionStart' module: 'CoreMotionPlugin'>. │
│ │
│ "Read latest sample — Float64Array of 13 elements" │
│ data := <primitive: 'primitiveMotionData' module: 'CoreMotionPlugin'>. │
│ "Elements: accelX,Y,Z (1-3), gyroX,Y,Z (4-6), magX,Y,Z (7-9), │
│ roll,pitch,yaw (10-12), timestamp (13)" │
│ │
│ "Stop updates" │
│ <primitive: 'primitiveMotionStop' module: 'CoreMotionPlugin'>. │
----- Original message -----
From: Richard O'Keefe raoknz@gmail.com
To: Any question about pharo is welcome pharo-users@lists.pharo.org
Cc: Aaron Wohl xphu@awohl.com
Subject: Re: [Pharo-users] iPad Pharo test release
Date: Sunday, March 01, 2026 7:10 PM
I have an iPad 6 (model A1893 if anyone cares).
Will Pharo run on that device?
How much storage do I need to install Pharo on this iPad?
(And TestFlight itself.)
I've never heard of the test store before; could the README in GitHub
be extended with instructions about how to install the beta?
If you had infinite time and I had money to pay for it ...
it would be nice to have a binding for Core Motion.
But having Pharo on the iPad? Huge thanks.
On Thu, 26 Feb 2026 at 02:19, Aaron Wohl via Pharo-users pharo-users@lists.pharo.org 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)