Follow-up — got 1.0.10 connected on Apple Silicon. Root cause of the “Offline” / “API timeout” errors (@davidturetsky, @joshputman)
Setup: MacBook Pro M4 Max, macOS 27.0.1, UltraWorkSpace V1.0.0-10, CoreBar on the same 2.4GHz Wi-Fi.
1.0.10 still fails on Apple Silicon. The app’s own log (launched from Terminal) shows three packaging problems:
1) Discovery: NSLocalNetworkUsageDescription is still missing in 1.0.10. As noted in post #2, macOS never prompts, the app never appears in Local Network, and UDP discovery on port 5319 is silently blocked. Adding the key and re-signing fixed discovery.
2) “Offline”: Qt uses the SecureTransport TLS backend. Log: ssl:Secure Transport, then SecureTransport does not support TLS 1.3 and [CoreBarConnectionTcp] Socket error: 20, Unable to init SSL Context. The CoreBar API on port 7431 is TLS 1.3 only, so the connection can never succeed. This is likely the “SSL issue” from 1.0.9, and it isn’t fixed on Apple Silicon.
3) The OpenSSL backend can’t load: the bundled libssl.3.dylib and libcrypto.3.dylib are x86_64 only. The app runs as arm64, so libqopensslbackend reports “Failed to load libssl/libcrypto” and Qt falls back to SecureTransport.
Fix I applied locally: removed PlugIns/tls/libqsecuretransportbackend.dylib, replaced the two OpenSSL dylibs with arm64 OpenSSL 3 builds (install names set to @rpath and @loader_path), and re-signed ad-hoc. Result: ssl:OpenSSL 3.6.4, connect succeed, request token succeed, CoreBar state 2 (online).
Suggested fixes for the release build:
- Add NSLocalNetworkUsageDescription to Info.plist
- Bundle universal (arm64 + x86_64) libssl/libcrypto, and/or call
QSslSocket::setActiveBackend("openssl")
- Remove the SecureTransport TLS plugin (deprecated, no TLS 1.3)
- Sign with a Developer ID and notarize (currently ad-hoc, bundle ID
com.yourcompany.UltraWorkSpace)
- Minor: the device certificate’s CN is
ultrabar.local, so connecting by IP logs a hostname-mismatch SSL error. It still connects.
Happy to share full logs.
Update (Oct 11): App widgets can’t be added (every item in the App list is greyed out)
Setup: UltraWorkSpace V1.0.0-10 on macOS (Apple Silicon), CoreBar on LineOS 1.0.8 / CoreBridge 1.0.3.
Steps: Widget List → App. All installed apps are listed (Calculator, Alarmclock, Space Dodger, White Noise, AuroraSniper), but they’re greyed out and none can be dragged onto the CoreBar.
Log (app launched from Terminal), once for each app every time the list loads:
[E] [CBAppWidgetItem] new CBAppWidgetItem error:[json.exception.out_of_range.403] key 'application' not found
Dragging an item then sends an empty config, and the drop is rejected:
[D] [CoreBarDeviceUI] mime data:{"config":null,"from":"configPanel","id":86,"widgetType":"app"}
Cause: the CoreBar’s app list (act 1002, sys.widget.apps) returns items with no application key:
{"icon":"http://<corebar>:8080/widget/icon?id=com.ultrabar.calculator&type=application&scheme=30",
"id":"com.ultrabar.calculator","last":true,"name":"Calculator","type":"APPS"}
The Mac app requires application, so every item fails to load.
Suggested fix: in CBAppWidgetItem, treat application as optional and fall back to id for the package name (or use json.value("application", item["id"])). Alternatively, have LineOS include application in the 1002 response.
Workaround: adding the widget row to the project file by hand with deploymentData: {"id": "<package>", "name": "...", "type": "APPS", "icon": "<icon url>"} deploys fine, and the tile launches the app on the CoreBar. So the bar side works; only the Mac app’s list parsing is broken.
Crash
OK
Thank you for the hard work on this.