Skip to content

Revive the HelloiOS app#9013

Merged
abadams merged 40 commits intomainfrom
abadams/revive_hello_ios-xcode
Mar 20, 2026
Merged

Revive the HelloiOS app#9013
abadams merged 40 commits intomainfrom
abadams/revive_hello_ios-xcode

Conversation

@abadams
Copy link
Member

@abadams abadams commented Mar 12, 2026

This resurrects the HelloiOS app. Alex and I would really appreciate someone with xcode and an iphone or ipad device taking it for a spin on a real device, because we had a hell of a time just getting it right for the two of us. Start by building and installing (to a local folder) Halide via cmake and then check the README in the app.

Still to do before merging is making CI build the app for simulator on mac.

Fixes #8730

abadams and others added 26 commits March 5, 2026 13:23
The xcode project still shells out to build the generators, which is not
ideal. But there's a host-arch test file now that's built with cmake, so
we can at least make sure the generators don't rot.

Co-authored-by: Claude Code <noreply@anthropic.com>
The HelloiOS build must run on macOS and be invoked twice. It isn't a
superbuild, and we wouldn't want to inject a superbuild here anyway.
@alexreinking
Copy link
Member

We've noticed a problem here: it seem the Xcode dependency analysis is missing a link somewhere and it requires two builds for the generator output to update after making a change.

Copy link
Member

@alexreinking alexreinking left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving with the caveat that this isn't perfect, see #9049

@abadams
Copy link
Member Author

abadams commented Mar 19, 2026

Haven't merged because this still isn't tested on CI. I don't see how to integrate this into the cmake apps testing setup and it's not really testable via the makefile (because it relies on a cmake install package of Halide). I could have "make distrib" produce a cmake-compatible install package, but that's pretty perverse. I also don't want to make a bespoke runner just for this one app.

@alexreinking
Copy link
Member

Haven't merged because this still isn't tested on CI. I don't see how to integrate this into the cmake apps testing setup and it's not really testable via the makefile (because it relies on a cmake install package of Halide). I could have "make distrib" produce a cmake-compatible install package, but that's pretty perverse. I also don't want to make a bespoke runner just for this one app.

I added a workflow to test the app here.

@alexreinking
Copy link
Member

fuzz_bounds failures:

Seed: 8412040097261433877
can't prove upper bound: (1 <= 0)
a = (uint1)1
b = (uint1)1
c = (uint1)0
d = (uint1)0
e = (uint1)1
int32x2(uint1x2(ramp(int32((uint1)c), int32(uint1(int32((uint1)e)) && (uint1)0), 2)) || uint1x2(ramp(int32((uint1)e), -25, 2) % int32x2(ramp(uint32((uint1)b), (uint32)4294967286, 2))))
[0, 0]
In vector lane 1:
int32(uint1(int32((uint1)c)) || uint1((int32((uint1)e) + -25) % int32(uint32((uint1)b) + (uint32)4294967286))) -> 1
scope {
	a : [(uint1)1, (uint1)1]
	b : [(uint1)1, (uint1)1]
	c : [(uint1)0, (uint1)0]
	d : [(uint1)0, (uint1)1]
	e : [(uint1)0, (uint1)1]
}

and

Seed: 412326383347904392
can't prove upper bound: ((uint16)1 <= (uint16)0)
a = (uint8)61
b = (uint8)79
c = (uint8)36
d = (uint8)94
e = (uint8)104
uint16x4(int32x4(ramp(x2(uint32((uint8)e)), x2((uint32)4294967174), 2)) > x4(int32((uint8)a)))
[(uint16)1, (uint16)0]
In vector lane 0:
uint16(int32(uint32((uint8)e)) > int32((uint8)a)) -> (uint16)1
scope {
	a : [(uint8)61, (uint8)61]
	b : [(uint8)77, (uint8)98]
	c : [(uint8)7, (uint8)37]
	d : [(uint8)88, (uint8)95]
	e : [(uint8)82, (uint8)113]
}

@abadams abadams merged commit bcdaedb into main Mar 20, 2026
24 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add testing for HelloiOS

2 participants