https://keiver.dev 2026-07-19T01:03:17.789Z Next.js using Feed Keiver Hernandez contact@keiver.dev https://keiver.dev Personal workspace and lab for experiments, tools, prototypes and articles https://keiver.dev/favicon-32x32.png https://keiver.dev/favicon.ico All rights reserved 2026, Keiver Hernandez https://keiver.dev/lab/image-tiler-mcp-server 2026-02-26T00:00:00.000Z

Keiver https://keiver.dev https://keiver.dev/lab/lazywebp 2026-02-10T00:00:00.000Z

Keiver https://keiver.dev https://keiver.dev/lab/tvos-assets 2026-02-01T00:00:00.000Z

Keiver https://keiver.dev https://keiver.dev/lab/expo-tvos-search 2026-01-21T00:00:00.000Z

Keiver https://keiver.dev https://keiver.dev/lab/poster-generator 2026-01-14T00:00:00.000Z

Keiver https://keiver.dev https://keiver.dev/lab/image-metadata-remover 2026-01-04T00:00:00.000Z

Keiver https://keiver.dev https://keiver.dev/lab/araname 2025-06-23T00:00:00.000Z

Keiver https://keiver.dev https://keiver.dev/lab/cubita 2025-05-07T00:00:00.000Z

Keiver https://keiver.dev https://keiver.dev/lab/mojigrid 2025-03-17T00:00:00.000Z

Keiver https://keiver.dev https://keiver.dev/lab/symbolmind 2025-03-10T00:00:00.000Z

Keiver https://keiver.dev https://keiver.dev/lab/facel 2025-02-24T00:00:00.000Z

Keiver https://keiver.dev https://keiver.dev/lab/full-unicode-viewer-with-favorite-blocks 2025-02-08T00:00:00.000Z

Keiver https://keiver.dev https://keiver.dev/lab/apple-watch-app-with-react-native-bidirectional-communication 2024-12-19T00:00:00.000Z

{ WATCH_NUMBER_EVENT: string } sendUpdateToWatch(update: { weight?: number unit?: string label?: string logs?: string }): Promise<{ status: string }> addListener(eventName: string): void removeListeners(count: number): void } export default TurboModuleRegistry.getEnforcing("RCTWatchConnectivitySpec") ``` ## Watch Implementation The main files in the watchOS extension are [ContentView.swift](https://github.com/keiver/barlog/blob/main/ios/barlog-watch%20Watch%20App/ContentView.swift) and [WatchConnectivityManager.swift](https://github.com/keiver/barlog/blob/main/ios/barlog-watch%20Watch%20App/WatchConnectivityManager.swift). The first is the UI implementation, and the second is the connectivity logic. ```swift import SwiftUI import WatchKit struct ContentView: View { @StateObject private var connectivityManager = WatchConnectivityManager.shared @StateObject private var model = NumberModel() @State private var rotationValue: Double = 0 @State private var showHelp: Bool = false @State private var displayLabel: String = "0" @State private var lastUpdateTimestamp: TimeInterval = 0 @State private var unit: String = "lb" @State private var lastLogs: String? = nil @FocusState private var isFocused: Bool let yellow = UIColor(red: 255.0 / 255.0, green: 183.0 / 255.0, blue: 3.0 / 255.0, alpha: 1.0) let green = UIColor(red: 0.0 / 255.0, green: 255.0 / 255.0, blue: 0.0 / 255.0, alpha: 1.0) var body: some View { GeometryReader { geometry in VStack { Spacer() // Yellow number for target weight Text(displayLabel) .font(.system(size: 45)) .foregroundColor(Color(yellow)) .frame(maxWidth: .infinity) .focusable(true) .focused($isFocused) .shadow(radius: 5) .digitalCrownRotation( $rotationValue, from: 0, through: 800, by: 1, sensitivity: .medium, isContinuous: false, isHapticFeedbackEnabled: true ) .onChange(of: rotationValue) { _ in handleRotationChange() } // Add modern haptics if available .modifier(SensoryFeedbackModifier(value: rotationValue)) // Green text for logs if let logs = lastLogs { Text(logs) .font(.footnote) .foregroundColor(Color(green)) .padding(10) .font(.body) .multilineTextAlignment(.center) .padding(.top, 4) // Actions under logs HStack(spacing: 20) { // Reset button Button(action: resetTo95) { Text("Reset") .font(.caption2) .foregroundColor(.blue) } .padding(.top, 12) // Info button Button(action: { showHelp.toggle() }) { Image(systemName: "questionmark.circle") .font(.caption2) .foregroundColor(.blue) } .padding(.top, 12) } .padding(.horizontal, 17) } else { Text("Open app to see plates") .padding(10) .font(.body) .multilineTextAlignment(.center) } Spacer() // Phone connectivity status if !connectivityManager.isReachable { Text("Phone Not Connected") .font(.footnote) .foregroundColor(.red) .padding(.bottom, 4) } } .frame(width: geometry.size.width) } .edgesIgnoringSafeArea(.all) .onAppear { isFocused = true } .onReceive(connectivityManager.$receivedMessage) { message in if let weight = message["weight"] as? Double { if weight > 0 { rotationValue = weight } } if let l = message["label"] as? String, !l.isEmpty { displayLabel = l } if let u = message["unit"] as? String { unit = u } if let logs = message["logs"] as? String { lastLogs = logs } } .sheet(isPresented: $showHelp) { HelpView() } } ... ``` ## React Native Integration I'm using the [useWatch.tsx](https://github.com/keiver/barlog/blob/main/src/hooks/useWatch.tsx) hook to to manage the module's state and communication with the watch. This hook is used in the main component to send updates to the watch and receive events from it. ```typescript import { useEffect, useRef, useCallback } from "react" import WatchModule, { WatchUpdate, WatchNumberEvent } from "@/WatchModule" import { EmitterSubscription } from "react-native" interface UseWatchConfig { onNumberReceived?: (number: number) => void enabled?: boolean } interface WatchState { sendUpdate: (update: WatchUpdate) => void } export function useWatch({ onNumberReceived, enabled = true }: UseWatchConfig): WatchState { const subscription = useRef void }>() const isUserInteraction = useRef(false) // Init watch listener useEffect(() => { if (!enabled) return subscription.current = WatchModule.addListener((event: WatchNumberEvent) => { if (!event.number) return if (!isUserInteraction.current) { onNumberReceived?.(event.number) } }) return () => { if (subscription.current) { subscription.current.remove() } } }, [enabled, onNumberReceived]) const sendUpdate = useCallback( (update: WatchUpdate) => { if (!enabled) return isUserInteraction.current = true console.log("Sending update to watch", update) WatchModule.sendUpdateToWatch(update).finally(() => { isUserInteraction.current = false }) }, [enabled] ) return { sendUpdate } } ``` ## Communication Flow The communication between the React Native app and Apple Watch is bidirectional and event-driven, using Apple's WatchConnectivity framework. #### From React Native to Watch: 1. RootLayout.tsx triggers an update through useWatch hook 2. WatchModule.ts sends message via TurboModule 3. RCTWatchConnectivityModule sends message through WCSession 4. WatchConnectivityManager.swift receives and publishes message 5. ContentView.swift updates UI based on received data #### From Watch to React Native: 1. ContentView.swift triggers updates via Digital Crown 2. WatchConnectivityManager.swift sends message via WCSession 3. RCTWatchConnectivityModule receives and processes message 4. WatchModule.ts emits event to JS 5. useWatch hook notifies subscribers ```mermaid %%{init: { 'theme': 'base', 'themeVariables': { 'clusterBkg': '#a3cb38', 'clusterBkg2': '#45aaf2', 'clusterBkg3': '#ffc914', 'fontFamily': 'arial', 'clusterBorder': '#333', 'nodeBorder': '#666' }, 'flowchart': { 'htmlLabels': true, 'curve': 'basis', 'nodeSpacing': 50, 'rankSpacing': 50, 'padding': 15 } }}%% flowchart TB classDef default rx:14,ry:14,fill:#fff,color:#333,stroke:#666 classDef watchCluster fill:#a3cb38,color:#333,stroke:#333,rx:36,ry:36 classDef iosCluster fill:#45aaf2,color:#fff,stroke:#333,rx:36,ry:36 classDef rnCluster fill:#ffc914,color:#333,stroke:#333,rx:36,ry:36 subgraph Watch["Apple Watch"] CV[ContentView.swift] WM[WatchConnectivityManager.swift] end subgraph iOS["iOS Native"] WCS[WCSession] RCTM[RCTWatchConnectivityModule.mm] end subgraph RN["React Native"] WModule[WatchModule.ts] Root[RootLayout.tsx] Hook[useWatch.ts] end %% React Native to Watch flow Root --trigger update through hook--> Hook Hook --send message via TurboModule--> WModule WModule --send via native module--> RCTM RCTM --send through WCSession--> WCS WCS --receive and publish message--> WM WM --publish receivedMessage--> CV %% Watch to React Native flow CV --Digital Crown updates--> WM WM --send through WCSession--> WCS WCS --receive and process--> RCTM RCTM --emit via TurboModule--> WModule WModule --notify subscribers--> Hook Hook --update React Native UI--> Root class Watch watchCluster class iOS iosCluster class RN rnCluster ``` Note: Both sides implement message queuing and retry mechanisms, while [WatchConnectivityManager.swift](https://github.com/keiver/barlog/blob/main/ios/barlog-watch%20Watch%20App/WatchConnectivityManager.swift) and [RCTWatchConnectivityModule.mm](https://github.com/keiver/barlog/blob/main/ios/WatchConnectivity/RCTWatchConnectivityModule.mm) handle session lifecycle and reachability. ## Conclusion The new React Native architecture and TurboModules provide a robust and efficient way to implement native modules with strong typing and minimal bridge overhead. This approach to bidirectional communication between React Native and Apple Watch demonstrates its power and flexibility. I'm still used to the old bridge-based communication, but switching to TurboModules has been a great experience. Please reach out if something should be done differently. I'm always open to suggestions and improvements. Thanks for reading! [contact@keiver.dev](contact@keiver.dev) ## More Resources 1. [Apple Watch WatchConnectivity](https://developer.apple.com/documentation/watchconnectivity) 2. [React Native](https://reactnative.dev/architecture/overview) 3. [React Native Codegen](https://reactnative.dev/docs/the-new-architecture/what-is-codegen) 4. [Project Repository](https://github.com/keiver/barlog) ]]> Keiver https://keiver.dev https://keiver.dev/lab/barlog 2024-12-12T00:00:00.000Z

Keiver https://keiver.dev https://keiver.dev/lab/tomotv 2024-11-22T00:00:00.000Z

Keiver https://keiver.dev https://keiver.dev/lab/apple-vision-vs-yolov11n-for-face-detection-experiment 2024-11-20T00:00:00.000Z

0 ? Double(processedFrames) / totalProcessingTime : 0 } var peakMemoryUsage: UInt64 = 0 var lastMemoryReset: Date = Date() } struct VideoProcessingConfig { var detectionQuality: String var sceneType: String var trackingPriority: String var confidenceThreshold: Float = 0.5 var frameInterval: Double = 1.0 } final class VisionFaceDetector { private var sequenceRequestHandler: VNSequenceRequestHandler private var metrics: DetectionMetrics private let ciContext = CIContext(options: [ .cacheIntermediates: false, .useSoftwareRenderer: false ]) init() { self.sequenceRequestHandler = VNSequenceRequestHandler() self.metrics = DetectionMetrics() } private func configureDetectionRequest(config: VideoProcessingConfig?) -> VNDetectFaceRectanglesRequest { let request = VNDetectFaceRectanglesRequest() // Use latest revision - big difference in accuracy request.revision = VNDetectFaceRectanglesRequestRevision3 if let config = config { switch config.detectionQuality { case "fast": request.usesCPUOnly = true if #available(iOS 16.0, *) { request.preferBackgroundProcessing = false } case "accurate": request.usesCPUOnly = false if #available(iOS 16.0, *) { request.preferBackgroundProcessing = true } default: // balanced request.usesCPUOnly = false if #available(iOS 16.0, *) { request.preferBackgroundProcessing = false } } } return request } func detectFaces(in pixelBuffer: CVPixelBuffer, confidenceThreshold: Float) throws -> [VNDetectedObjectObservation] { let request = configureDetectionRequest(config: nil) let requestHandler = VNImageRequestHandler( cvPixelBuffer: pixelBuffer, orientation: .up, options: [VNImageOption.ciContext: ciContext] ) try requestHandler.perform([request]) guard let observations = request.results as? [VNFaceObservation] else { return [] } return observations .filter { $0.confidence >= confidenceThreshold } .map { faceObservation in // Add some padding to the bounding box let box = faceObservation.boundingBox let verticalPadding = box.height * 0.25 let horizontalPadding = box.width * 0.1 let paddedBox = CGRect( x: max(0, box.minX - horizontalPadding), y: max(0, box.minY - verticalPadding), width: min(1 - box.minX, box.width + (2 * horizontalPadding)), height: min(1 - box.minY, box.height + (2 * verticalPadding)) ) return VNDetectedObjectObservation( boundingBox: paddedBox ).withConfidence(faceObservation.confidence) } } } ``` ## ### YOLOv11n Setup For YOLOv11n, first you need to convert the model. Here's the Python script I used in an M1 Mac: ## Check the YOLOv11n Model by Ultralytics in [Huggingface](https://huggingface.co/Ultralytics/YOLO11) page for more details. I used the smallest model for this project(n). The model is trained on the [COCO](https://docs.ultralytics.com/datasets/detect/coco/) dataset, so it's a good starting point for general object detection. ## ```python from ultralytics import YOLO # Load YOLO model model = YOLO("yolo11n.pt") # Export to CoreML # Pro tip: Run this on a machine with 16GB+ RAM model.export(format="coreml", nms=True, # Enable Neural Network Management System, I left it off for now input_shape=(1, 3, 640, 640), # This is important - include batch dimension scales=1/255.0, # Normalize inputs biases=[0, 0, 0]) # Quick test coreml_model = YOLO("yolo11n.mlpackage") results = coreml_model("test_image.jpg") ``` ## Core ML Model Conversion When examining the YOLO11n Core ML model's category mapping, always check the output categories. Here's an example of the YOLO11n model's category mapping where the first category is "person", so we use index 0 for face detection: ## ```json { "MLModelVersionStringKey": "8.3.28", "MLModelDescriptionKey": "Ultralytics YOLO11n model trained on /usr/src/ultralytics/ultralytics/cfg/datasets/coco.yaml", "MLModelCreatorDefinedKey": { "com.github.apple.coremltools.version": "8.0", "stride": "32", "com.github.apple.coremltools.source_dialect": "TorchScript", "docs": "https://docs.ultralytics.com", "task": "detect", "com.github.apple.coremltools.source": "torch==2.4.0", "imgsz": "[640, 640]", "date": "2024-11-09T19:33:44.912605", "batch": "1", "names": "{0: 'person', 1: 'bicycle', 2: 'car', 3: 'motorcycle', 4: 'airplane', 5: 'bus', 6: 'train', 7: 'truck', 8: 'boat', 9: 'traffic light', 10: 'fire hydrant', 11: 'stop sign', 12: 'parking meter', 13: 'bench', 14: 'bird', 15: 'cat', 16: 'dog', 17: 'horse', 18: 'sheep', 19: 'cow', 20: 'elephant', 21: 'bear', 22: 'zebra', 23: 'giraffe', 24: 'backpack', 25: 'umbrella', 26: 'handbag', 27: 'tie', 28: 'suitcase', 29: 'frisbee', 30: 'skis', 31: 'snowboard', 32: 'sports ball', 33: 'kite', 34: 'baseball bat', 35: 'baseball glove', 36: 'skateboard', 37: 'surfboard', 38: 'tennis racket', 39: 'bottle', 40: 'wine glass', 41: 'cup', 42: 'fork', 43: 'knife', 44: 'spoon', 45: 'bowl', 46: 'banana', 47: 'apple', 48: 'sandwich', 49: 'orange', 50: 'broccoli', 51: 'carrot', 52: 'hot dog', 53: 'pizza', 54: 'donut', 55: 'cake', 56: 'chair', 57: 'couch', 58: 'potted plant', 59: 'bed', 60: 'dining table', 61: 'toilet', 62: 'tv', 63: 'laptop', 64: 'mouse', 65: 'remote', 66: 'keyboard', 67: 'cell phone', 68: 'microwave', 69: 'oven', 70: 'toaster', 71: 'sink', 72: 'refrigerator', 73: 'book', 74: 'clock', 75: 'vase', 76: 'scissors', 77: 'teddy bear', 78: 'hair drier', 79: 'toothbrush'}" }, "MLModelAuthorKey": "Ultralytics", "MLModelLicenseKey": "AGPL-3.0 License (https://ultralytics.com/license)" } ``` ## YOLOVideoDetector Implementation ```swift final class YOLOVideoDetector { private var model: yolo11n? private let modelInputSize = CGSize(width: 640, height: 640) private let personClassIndex = 0 // Using person detection for faces private let context: CIContext private var metrics: DetectionMetrics private var pixelBufferPool: CVPixelBufferPool? init() { self.context = CIContext(options: [.useSoftwareRenderer: false]) self.metrics = DetectionMetrics() setupPixelBufferPool(width: Int(modelInputSize.width), height: Int(modelInputSize.height)) } func initializeModel(completion: @escaping (Result) -> Void) { DispatchQueue.global(qos: .userInitiated).async { [weak self] in do { let config = MLModelConfiguration() // Using cpuAndGPU instead of .all for more consistent performance // .all can sometimes cause frame drops when switching between compute units config.computeUnits = .cpuAndGPU config.allowLowPrecisionAccumulationOnGPU = true self?.model = try yolo11n(configuration: config) DispatchQueue.main.async { completion(.success(())) } } catch { DispatchQueue.main.async { completion(.failure(error)) } } } } func detectFaces(in pixelBuffer: CVPixelBuffer, confidenceThreshold: Float) throws -> [VNDetectedObjectObservation] { guard let model = model else { throw DetectionError.modelNotInitialized } // Check memory usage every 100 frames, this is tricky and could be improved if metrics.processedFrames % 100 == 0 && reportMemoryUsage() > 500_000_000 { // 500Mb throw DetectionError.memoryLimitExceeded } let resizedBuffer = try resizePixelBuffer(pixelBuffer) let input = yolo11nInput(image: resizedBuffer) let output = try model.prediction(input: input) return try processYOLODetections( predictions: output.var_1227, confidenceThreshold: confidenceThreshold, originalSize: CGSize( width: CVPixelBufferGetWidth(pixelBuffer), height: CVPixelBufferGetHeight(pixelBuffer) ) ) } private func processYOLODetections( predictions: MLMultiArray, confidenceThreshold: Float, originalSize: CGSize ) throws -> [VNDetectedObjectObservation] { // Extract person detections and convert to face observations // Format: [batch, anchor, x, y, w, h, confidence, class_scores] var detections: [VNDetectedObjectObservation] = [] let numPredictions = predictions.shape[1].intValue for i in 0..= confidenceThreshold, classIndex == Float(personClassIndex) else { continue } let x = CGFloat(predictions[[0, i, 0]].doubleValue) let y = CGFloat(predictions[[0, i, 1]].doubleValue) let w = CGFloat(predictions[[0, i, 2]].doubleValue) let h = CGFloat(predictions[[0, i, 3]].doubleValue) // Convert to normalized coordinates let boundingBox = CGRect( x: x / originalSize.width, y: y / originalSize.height, width: w / originalSize.width, height: h / originalSize.height ) detections.append( VNDetectedObjectObservation( boundingBox: boundingBox ).withConfidence(confidence) ) } return detections } private func resizePixelBuffer(_ pixelBuffer: CVPixelBuffer) throws -> CVPixelBuffer { var resizedBuffer: CVPixelBuffer? if let pool = pixelBufferPool { CVPixelBufferPoolCreatePixelBuffer( kCFAllocatorDefault, pool, &resizedBuffer ) } guard let resizedBuffer = resizedBuffer else { throw DetectionError.imageProcessingFailed } let ciImage = CIImage(cvPixelBuffer: pixelBuffer) let scaleX = modelInputSize.width / CGFloat(CVPixelBufferGetWidth(pixelBuffer)) let scaleY = modelInputSize.height / CGFloat(CVPixelBufferGetHeight(pixelBuffer)) let scale = min(scaleX, scaleY) context.render( ciImage.transformed(by: CGAffineTransform(scaleX: scale, y: scale)), to: resizedBuffer ) return resizedBuffer } private func setupPixelBufferPool(width: Int, height: Int) { let attributes = [ kCVPixelBufferPoolMinimumBufferCountKey: 3, kCVPixelBufferPixelFormatTypeKey: kCVPixelFormatType_32BGRA, kCVPixelBufferWidthKey: width, kCVPixelBufferHeightKey: height ] as CFDictionary CVPixelBufferPoolCreate( kCFAllocatorDefault, attributes, nil, &pixelBufferPool ) } private func reportMemoryUsage() -> UInt64 { var info = mach_task_basic_info() var count = mach_msg_type_number_t(MemoryLayout.size)/4 let kerr: kern_return_t = withUnsafeMutablePointer(to: &info) { $0.withMemoryRebound(to: integer_t.self, capacity: 1) { task_info( mach_task_self_, task_flavor_t(MACH_TASK_BASIC_INFO), $0, &count ) } } return kerr == KERN_SUCCESS ? info.resident_size : 0 } } ``` ## ## Real-World Performance Let me share my practical experience from testing both detectors across a range of real video inputs during development: ### Processing Speed Vision demonstrated consistently better performance: > Vision typically maintained 25-30 FPS on most devices, even with multiple faces in the frame > YOLO showed 15-20 FPS on the same devices, dropping to 8-12 FPS on older models ## ```swift // Configuration that worked best for Vision let visionConfig = VideoProcessingConfig( detectionQuality: "balanced", sceneType: "default", trackingPriority: "balanced" ) visionConfig.confidenceThreshold = 0.12 // Sweet spot for faces visionConfig.frameInterval = 0.75 // Process every 3/4 frames // YOLO needed more conservative settings let yoloConfig = VideoProcessingConfig( detectionQuality: "balanced", sceneType: "default", trackingPriority: "detection" ) yoloConfig.confidenceThreshold = 0.25 // Needed higher to avoid false positives yoloConfig.frameInterval = 1.0 // Process every other frame ``` ### Memory Usage My testing showed Vision to be more memory-efficient: Vision: - Stable memory usage around 80-120MB - Peak usage rarely exceeded 150MB - No significant memory growth over 1-hour sessions ## YOLO: - Base memory footprint of 200-250MB - Peak usage up to 400MB during detection - Required memory reset after ~2 hours of continuous use ### Power Consumption Not tested in detail, but Vision seemed to consume less power overall. ### Accuracy Both frameworks performed well, with some notable differences: ## Vision: - 95% accuracy on front-facing faces - 85% accuracy on profile views - Reliable detection down to 64x64 pixels - False positive rate < 0.1% ## YOLO: - 92% accuracy on front-facing faces - 88% accuracy on profile views - Minimum reliable face size: 96x96 pixels - False positive rate ~0.5% ## Common Issues & Fixes ### Vision Framework Memory Leaks: Always use autoreleasepool when processing frames: ## ```swift while let sampleBuffer = output.copyNextSampleBuffer() { autoreleasepool { // Process frame CMSampleBufferInvalidate(sampleBuffer) } } ``` ## Poor Performance: Make sure to handle orientation correctly: ## ```swift let requestHandler = VNImageRequestHandler( cvPixelBuffer: pixelBuffer, orientation: .up, // Critical for correct detection options: [VNImageOption.ciContext: ciContext] ) ``` ### YOLOv11n Conversion Issues: Clear GPU memory before converting: ## ```python import torch torch.cuda.empty_cache() import gc gc.collect() model.export(format="coreml", ...) ``` ## Random Crashes: Proper error handling is crucial: ## ```swift func detectFaces() throws { guard let model = model else { throw DetectionError.modelNotInitialized } if reportMemoryUsage() > 500_000_000 { // 500MB throw DetectionError.memoryLimitExceeded } // Process frame here } ``` ## What to use After all this testing, Vision shows an edge over YOLO for basic face detection on iOS: ## - Faster processing - Lower memory usage - Better accuracy on faces specifically - Native iOS integration - No need to manage model updates ## That said, YOLO could be your better choice if: ## - You need general object detection too - You want to train custom models - You need cross-platform compatibility ## Final Tips For Vision: ```swift // Always add padding to face boxes let paddedBox = boundingBox.insetBy( dx: -boundingBox.width * 0.1, dy: -boundingBox.height * 0.25 ) ``` ## For YOLO: ## ```swift // Reuse pixel buffers for better performance private var pixelBufferPool: CVPixelBufferPool? private func setupPixelBufferPool(width: Int, height: Int) { let attributes = [ kCVPixelBufferPoolMinimumBufferCountKey: 3, kCVPixelBufferPixelFormatTypeKey: kCVPixelFormatType_32BGRA, kCVPixelBufferWidthKey: width, kCVPixelBufferHeightKey: height ] as CFDictionary CVPixelBufferPoolCreate( kCFAllocatorDefault, attributes, nil, &pixelBufferPool ) } ``` ## Testing Videos I used these videos to test both detectors: ## @[video](ForBiggerBlazes.mp4){width: 640, height: 360, autoplay: false, preload: true} ## - Vision: 28 FPS, 98% detection rate, 110MB avg memory - YOLO: 18 FPS, 95% detection rate, 280MB avg memory - Scene characteristics: Good lighting, multiple face angles ## @[video](aForBiggerMeltdowns.mp4){width: 640, height: 360, autoplay: false, preload: false} ## - Vision: 27 FPS, 92% detection rate, 115MB avg memory - YOLO: 17 FPS, 94% detection rate, 285MB avg memory - Scene characteristics: Variable lighting, fast motion ## @[video](IMG_8335w.mov){width: 360, height: 640, autoplay: false, preload: false} ## - Vision: 29 FPS, 0% detection rate, 105MB avg memory (no faces) - YOLO: 19 FPS, 0% detection rate, 275MB avg memory (no faces) - Scene characteristics: Outdoor lighting, 0 faces ## @[video](WeAreGoingOnBullrunVideo.mp4){width: 640, height: 360, autoplay: false, preload: false} ## - Vision: 26 FPS, 91% detection rate, 120MB avg memory - YOLO: 16 FPS, 89% detection rate, 290MB avg memory - Scene characteristics: Outdoor, motion blur, varying distances ## References and Further Reading ### Official Documentation 1. [Vision Framework Documentation](https://developer.apple.com/documentation/vision) - Apple's official documentation for the Vision framework - Includes VNDetectFaceRectanglesRequest API reference ## 2. [Ultralytics YOLO Documentation](https://docs.ultralytics.com/) - Official documentation for YOLO models - Implementation guides and best practices ### Academic Publications 3. Redmon, J., & Farhadi, A. (2018). "YOLOv3: An Incremental Improvement." arXiv preprint arXiv:1804.02767. - Foundational paper on YOLO architecture - Presents core concepts still relevant to modern implementations ## 4. Bochkovskiy, A., Wang, C. Y., & Liao, H. Y. M. (2020). "YOLOv4: Optimal Speed and Accuracy of Object Detection." arXiv preprint arXiv:2004.10934. - Comprehensive analysis of YOLO architecture improvements - Performance optimization techniques ### Technical Resources 5. [Core ML Tools Documentation](https://coremltools.readme.io/) - Official documentation for converting models to Core ML format - Best practices for iOS deployment ## 6. [WWDC 2023 Sessions](https://developer.apple.com/videos/wwdc2023) - Latest updates on Vision framework capabilities - Performance optimization techniques for iOS Note: For the most up-to-date information on YOLOv11n, please refer to the Ultralytics documentation and GitHub repository, as this represents ongoing development work. ## ## Conclusion Both Vision and YOLO are solid choices for face detection on iOS, but Vision's better performance and lower memory usage. If you need more flexibility or cross-platform compatibility, YOLO could be the better choice. ## Thanks for reading, and I hope this help even if just a bit, take the stats with a grain of salt since I used LLMs to get average numbers from my app test logs; there could be a lot of factors that could affect the performance of the detectors, but this is a good starting point. Happy coding! [contact@keiver.dev](contact@keiver.dev) > Archived, migrating native modules to new React Native architecture. ]]> Keiver https://keiver.dev https://keiver.dev/lab/fullscreen-slider-barlog-experiment 2024-06-24T00:00:00.000Z

**Update**: Coach marks have been removed from the design, as they were found to be unnecessary and potentially distracting. Instead, the design now adds a subtle ruler like visual cue to indicate the direction of the slider.  > > `Fig 00: Ruler like visual cue to indicate the direction of the slider` ### 2. Dynamic Screen Height Adjustment The weight slider takes up the entire screen height, with each 'plate' dynamically fitting the available space. This makes the experience feel more natural and immersive since the whole screen is used for interaction. There are no fiddly controls; everything is big, visual, and easy to use. ### 3. Full-Screen Slider Interaction The full-screen design cuts away unnecessary distractions. It’s just you and the slider. This keeps things simple, makes the adjustments fast, and reduces any guesswork. The idea was to keep users focused, reduce cognitive load, and allow weight adjustments to be as straightforward as possible. ### 4. Text Representation for Accessibility For accessibility, there is also a text representation of each weight plate and how many are selected. For example, you might see something like "45lb x 1 · 15lb x 1". It’s important that everyone can use this app, and these text descriptions help users who rely on detailed feedback. ## Use Cases and Design Approaches ### Minimalist UI for Clarity - **Approach**: By making each plate fit the full height, the design maintains a minimal approach. No extra controls, no clutter—just what’s needed. - **Benefits**: It’s less overwhelming and makes it easy to adjust the weight. ### Focused Interaction Through Guidance - **Approach**: Coach marks guide new users, making sure they understand how to interact with the slider from the start. - **Benefits**: This reduces hesitation when users first open the app, leading to a much smoother onboarding process. ### Screen-Based Innovation in UI/UX - **Approach**: Instead of the usual sliders that take up a small part of the screen, this one uses **the entire screen**. - **Benefits**: This approach is more accessible for users with different hand sizes or mobility challenges. Making everything big and easy to interact with makes a huge difference.  > > `Fig 01: Selecting weight plates in the full-screen slider, check the prototype below for a closer look` ### Consistency Across Platforms - **Approach**: Designed with cross-platform consistency in mind, ensuring that both iOS and Android users have a similar experience. - **Benefits**: Reduces discrepancies between platforms, making it easier to maintain and ensuring a consistent experience. ## Drawbacks to This Approach Of course, here are some of the challenges I'm considering: 1. **Learning Curve for New Users**: Even with coach marks, it can take a little time for users to adjust if they’re used to traditional sliders. Some may need extra time to get comfortable with the concept. 2. **Device and Screen Size Limitations**: This design works well on most devices, but very small or unusually shaped screens can be challenging. Sometimes there just isn’t enough space to make it feel natural. 3. **Limited Multi-Tasking Capabilities**: The full-screen slider takes over everything, so if you like to multi-task or use split-screen features, it could feel restrictive on the wrong scenario. 4. **Gesture Conflicts with OS-Level Actions**: There could be issues with users swiping up from the bottom of their device, triggering OS-level gestures like closing the app, which would interfere with the slider. Considering using SafeAreas or other techniques to avoid this. ## Conclusion This experiment has been about rethinking what a weight adjustment slider could be—making it immersive, accessible, and enjoyable to use. It is not perfect, but it is a step towards something different, potentially even more engaging. I’d love to see this kind of full-screen interaction inspire other apps. Sliders and adjustment tools don’t always have to be small or tucked away—they can take center stage, making full use of the screen to create a more engaging experience. This approach also opens up opportunities for future iterations based on user behavior data. By continuously refining through user insights, I believe this design could become even more intuitive and user-friendly over time. ## Updated: 09/24/2024 For a closer look, [check the app here](https://keiver.dev/lab/barlog). ## Figma Prototype If you want to check out how this design works in more detail, here’s the **Figma prototype**: ## @[iframe](https://embed.figma.com/proto/GYjqdqOPqycj037o4Qo10H/Barup?page-id=61%3A5&node-id=61-2462&node-type=canvas&viewport=-372%2C499%2C0.56&scaling=scale-down&content-scaling=fixed&starting-point-node-id=61%3A19&show-proto-sidebar=1&embed-host=share){width="100%" height="650" allowfullscreen=true} ]]> Keiver https://keiver.dev https://keiver.dev/lab/canvas 2024-04-08T00:00:00.000Z

Keiver https://keiver.dev