Post

Replies

Boosts

Views

Activity

Reply to Explicitly Loading Third Party Dylibs Without Violating App Store Connect Policies
Progress! I hacked the BF code (in my local repo) and now I can connect to my Muse headset and distribute my app to TestFlight via App Store Connect! I changed line #42 in ble_lib_board.cpp to read: std::string lib_name = "../libsimpleble-c.dylib.framework/libsimpleble-c.dylib"; According the man page for dlopen(), a codesigned app with entitlements (which means any iOS app uploaded to the App Store) must use full paths for its dylibs. So my hack gives us a full path, but relative to the location of the calling binary, in this case libBoardController.dylib. According to an error message I received recently from App Store Connect, all frameworks must be located under /Frameworks, so that at least gives us a basis for forming the full paths. According to the same man page, dlopen() should also use @rpath, which is built into the calling dylib. That would be I think the optimal solution, so I will play with that next.
Apr ’24
Reply to The compiler is unable to type-check this expression in reasonable time in Xcode 12 with SwiftUI
I am getting the same compiler error using Xcode 13.2.1. The offending line of code is the NavigationLink, located at the bottom of the following, minimal reproducible sample. If I comment out that one line, the error goes away and the compile is almost instantaneous. Any suggestions? I've already tried using Strings instead of Ints for the tag/selection parameters. Same error. import SwiftUI import Foundation enum MarkerType: Double {   case unlabeled = -99   case end = -4   case start = -3   case stop = -2   case blank = -1   case image = 1 } class LabeledImage {   let image: Image   let marker: Double   var appeared = false       init(image: Image, marker: Double) {     self.image = image     self.marker = marker   } } struct SlideShow {   private let maxImages: Int = 10000   var images = [LabeledImage]()   var labels = [String]()   var totalImages: Int { return self.images.count }   private var fromFolder: URL       init(fromURL: URL = Bundle.main.bundleURL.appendingPathComponent("Contents/Resources/DefaultImages")) {     self.fromFolder = fromURL   } } class AppState: ObservableObject {   static var docDir: URL = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first!   @Published var isMainMenuActive = false   @Published var loadFolder: URL = Bundle.main.bundleURL.appendingPathComponent("Contents/Resources/DefaultImages")   @Published var intervalSeconds: Double = 0.6   var saveFolder = URL(fileURLWithPath: "BCILab", relativeTo: docDir)   var labels = [String]()   var totalImages: Int = 0   var saveIndex: Int = 0 } struct minsample: View {   @StateObject private var appState = AppState()   @State private var slideshow = SlideShow()   @State private var selection: Int = 0       private func insertAppears(_ marker: Double) {     let nmarker = marker + 100.0   }       var body: some View {     NavigationView {       ForEach(0..<slideshow.images.count-1, id: \.self) { i in         let thisImage = slideshow.images[i].image           .resizable()           .aspectRatio(contentMode: .fit)           .onAppear(perform: { insertAppears(slideshow.images[i].marker) })         let nextImage = slideshow.images[i+1].image           .resizable()           .aspectRatio(contentMode: .fit)           .onAppear(perform: { insertAppears(slideshow.images[i+1].marker) })         NavigationLink(destination: nextImage, tag: i, selection: self.$selection) { thisImage }       }     }   } }
Mar ’22
Reply to .onAppear() and .onDisappear() not running in child views (WatchOS 8 beta 4)
The same is happening with my code: onAppear() does not fire when the view on which it is called is nested too deeply. For example, if the body chain is ContentView->ViewController->MyView->Image, and the onAppear() is called on Image within the body of MyView, then it will not fire. However if Image is instead referenced within the body of ViewController, as a parameter to MyView, then onAppear will fire.
Feb ’22