Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
RZelaya
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
1.
▲
by
RZelaya
4mo ago
Once the Apple Silicon Macs came out, I converted my whole family from PC to Mac because the price to performance finally made sense. I'm the resident tech support for my family and some friends, so having them all playing in the Mac e
2.
▲
by
RZelaya
4mo ago
Good catch. Easy edge case to miss if you only test on QWERTY. I'll double-check the implementation, thanks for the heads up. update: You're right, this is a real bug. The Direct version's auto-paste hardcodes the QWERTY keyc
3.
▲
by
RZelaya
4mo ago
Thanks for sharing this. The "phase out the broadly-scoped Accessibility API and replace with narrower permissions" point is exactly the right structural fix. Right now developers have to declare a permission far broader than they
4.
▲
by
RZelaya
4mo ago
From what I understand Wispr Flow distributes directly from their website and doesn't ship through the Mac App Store, so they don't go through Apple's App Store review at all. They use the Accessibility API the same way the d
5.
▲
by
RZelaya
4mo ago
Apple's built-in dictation works for casual use, but in my own daily use the typo rate was high enough that I was constantly going back to fix things, which defeated the point (with a hand injury, those corrections cost me). WhisperPad
6.
▲
by
RZelaya
4mo ago
Same approach: CGEventPost with Accessibility permission. The wrinkle was that my App Store reviewer wasn't comfortable with how I was using AX permission for auto-paste, even though the mechanism is the same as other apps already in t
7.
▲
by
RZelaya
4mo ago
The direct version uses CGEventPost to synthesize the paste, which requires Accessibility permission. The App Store version writes to the clipboard only, so no AX permission needed and the user presses Cmd+V manually. The 2.4.5 rejection wa
8.
▲
by
RZelaya
4mo ago
Handy looks great. More tools in this space is a good thing for people who need them.
9.
▲
by
RZelaya
4mo ago
Fair points. The notarization-but-not-App-Store path was actually a workable middle ground in my case. Apple still gates security via notarization, but doesn't gatekeep the use case. The warnings users see when installing non-App-Store
10.
▲
by
RZelaya
4mo ago
The paste-phase failures are exactly where most of my hard problems have been. App switching mid-paste, focus changes, slow-loading fields. It's an ongoing battle. Transcription history and custom prompts (especially for code or techni
11.
▲
by
RZelaya
4mo ago
The acronym is unfortunate, you're not wrong. MITM here is "Moogle In The Machine" (the Final Fantasy moogle + machine learning), but the security-context joke is fair and I hear it constantly.
12.
▲
by
RZelaya
4mo ago
Fair. I run Nobara on my gaming computer and built a similar dictation tool there with no API restrictions, so the trade-off is real. For this project I chose both: App Store reach for the compliant version, direct distribution for the full
13.
▲
by
RZelaya
4mo ago
Useful context, thanks. I hadn't realized Google was tightening similarly. Would be interesting to see how the rationales compare.
14.
▲
by
RZelaya
4mo ago
I see, that's a really fair point. And I can understand that banking field example. So I can see why they're guarding against it. My disagreement was less with the rule itself and whether Whisperpad's specific use case for us
15.
▲
by
RZelaya
4mo ago
I am still not certain I understand exactly what Apple's reviewer meant by 2.4.5 in my case. My working assumption is that the concern is about an app reaching into every other app on the system to inject text, but I never got a perfec
16.
▲
by
RZelaya
4mo ago
The direct version is fully signed and notarized by Apple, just not distributed through the App Store. Anyone can install it from mitmllc.com/whisperpad without workarounds. The 2.4.5 rejection was an App Store rule, not a general rest
17.
▲
Apple rejected my dictation app for using the accessibility API
(mitmllc.com)
316 points
by
RZelaya
4mo ago
|
169 comments