iOS开发针对苹果新系统iOS26的兼容适配UITabBarButtonItem & UITabBar的液态玻璃效果/当前wifi ssid获取

1. UITabBarButtonItem液态玻璃效果

        兼容处理:

        第一种方式(不推荐):把所有的UITabBarButtonItem关闭液态玻璃效果:

 if (@available(iOS 26.0, *)) { self.navigationItem.rightBarButtonItem.hidesSharedBackground = YES; self.navigationItem.leftBarButtonItem.hidesSharedBackground = YES; } else { // Fallback on earlier versions }

        第二种方式:所有导航栏按钮全部采用UITabBarButtonItem,支持液态玻璃效果。

        第三种方式:降低Xcode版本到Xcode25及以下版本,然后再打包

        第四种方式:使用兼容模式显示传统UI风格,也就是取消TabBar液态玻璃效果:

        打开info.plist,添加一个Boolean键值对,取消液态玻璃效果,添加完成后重新运行,UITabBar恢复旧的样式:

<key>UIDesignRequiresCompatibility</key> <true/>

2.  采用UILayoutFittingExpandedSize设置自定义的navigationItem.titleView的内容尺寸,在iOS26上高度偏大,高度变为屏幕的高度,预期是高度应该为导航栏的高度;

原因:在iOS26之前UILayoutFittingExpandedSize最大尺寸限制在导航栏范围内,而在iOS26则允许充斥整个屏幕:

- (CGSize)intrinsicContentSize { return UILayoutFittingExpandedSize; }

        兼容处理:

        修改intrinsicContentSize,指定titleView的尺寸大小为导航栏大小:

 #define SCREEN_WIDTH ([[UIScreen mainScreen] respondsToSelector:@selector(nativeBounds)]?[UIScreen mainScreen].nativeBounds.size.width/[UIScreen mainScreen].nativeScale:[UIScreen mainScreen].bounds.size.width) - (CGSize)intrinsicContentSize { return CGSizeMake(SCREEN_WIDTH, 44); }

3、UITabBarController调用self.setValue(yourTabBar, forKey: "tabBar")自定义tabBar失效

        原因:iOS 26 之后对 UITabBarController 的 KVC 注入限制,导致无效,但不会crash

        兼容处理:

        方案1:使用兼容模式显示传统UI风格,也就是取消TabBar液态玻璃效果:

        打开info.plist,添加一个Boolean键值对,取消液态玻璃效果,添加完成后重新运行,UITabBar恢复旧的样式:

<key>UIDesignRequiresCompatibility</key> <true/>

        方案2:改为使用系统的UITabBarItem组件,能够支持新系统的液态玻璃效果

        方案3:降低Xcode版本到Xcode25及以下版本,然后再打包

4、创建一个由URL标识的代表任何资源的assert对象时报错:

AVAssetExportSessionStatusFailed: Error Domain=AVFoundationErrorDomain Code=-11800 "这项操作无法完成" UserInfo={ NSUnderlyingError=0x1586626a0 { Error Domain=NSOSStatusErrorDomain Code=-16979 "(null)" }, NSLocalizedFailureReason=发生未知错误(-16979), NSURL=file:///var/mobile/Media/DCIM/100APPLE/IMG_0426.MOV, NSLocalizedDescription=这项操作无法完成 }

        原因:AVAssetExportSession -11800 / -16979 转码失败,权限不足、文件不可读,创建一个由URL标识的代表任何资源的assert对象时,传入的originFilePath示例: file:///var/mobile/Media/DCIM/100APPLE/IMG_0426.MOV,没有读的权限,因为iOS 26对相册视频读取权限收紧,代码示例:

//originFilePath示例: file:///var/mobile/Media/DCIM/100APPLE/IMG_0426.MOV AVURLAsset *asset = [AVURLAsset URLAssetWithURL:originFilePath options:nil]; 

        兼容处理:先将相册的视频拷贝到 App 沙盒临时目录,然后再去创建资源对象AVURLAsset

 [self copyVideoToSandbox:originFilePath completion:^(NSURL *localUrl) { AVURLAsset *asset = [AVURLAsset URLAssetWithURL:localUrl options:nil]; }]; - (void)copyVideoToSandbox:(NSURL *)originUrl completion:(void (^)(NSURL *localUrl))completion { NSString *temp = [NSTemporaryDirectory() stringByAppendingPathComponent:@"tempVideo.mov"]; NSURL *localUrl = [NSURL fileURLWithPath:temp]; NSFileManager *fm = [NSFileManager defaultManager]; if ([fm fileExistsAtPath:temp]) { [fm removeItemAtPath:temp error:nil]; } NSError *err = nil; BOOL ok = [fm copyItemAtURL:originUrl toURL:localUrl error:&err]; if (!ok || err) { NSLog(@"拷贝失败: %@", err); completion(nil); return; } completion(localUrl); } 

5. 通过CNCopySupportedInterfaces获取wifi ssid的方式已失效:

 class func getWifiSSID() -> String? { var wifiName: let wifiInterfaces = CNCopySupportedInterfaces() if wifiInterfaces != nil { let interfaceArr = CFBridgingRetain(wifiInterfaces) as! [String] if interfaceArr.count > 0 { let interfaceName = interfaceArr[0] as CFString let ussafeInterfaceData = CNCopyCurrentNetworkInfo(interfaceName) if ussafeInterfaceData != nil { let interfaceData = ussafeInterfaceData as! [String: Any] wifiName = interfaceData["SSID"] as? String ?? "" } else { return nil } } } return wifiName }

        原因:iOS26不再推荐使用CNCopySupportedInterfaces,在iOS26将返回空值

        兼容处理:Capabilities添加Access WiFi Information权限;通过CLLocationManager确保有定位权限,然后使用NEHotspotNetwork获取wifi ssid:

NEHotspotNetwork.fetchCurrent { curNetwork in block(curNetwork?.ssid ?? "") }

Read more

使用AI进行代码审查

ai-code-review 在日常开发中,我们经常会遇到一些问题,比如代码质量问题、安全问题等。如果我们每次都手动去检查,不仅效率低下,而且容易出错。 所以我们可以利用 AI 来帮助我们检查代码,这样可以提高我们的效率 那么,如何利用 AI 来检查代码呢? 在这里我先厚着脸皮要下star吧。一款基于AI进行代码审核的插件。插件地址,希望大家能支持下。 1. 使用 JS 脚本 这种方法其实就是写一个简单的脚本,通过调用 OpenAI 的 API,将代码提交给 AI 进行评审。 这里我们需要使用 Node.js 来实现这个功能。利用 git 的 pre-commit hooks,在 git 提交前执行这个脚本。整体流程如下: 接下来我们来具体实现下代码。在项目根目录下新建一个pre-commit.js文件,这个文件就是我们的脚本。 1.

timed_out错误处理:传统方法与AI辅助的对比

快速体验 1. 打开 InsCode(快马)平台 https://www.inscode.net 2. 点击'项目生成'按钮,等待项目生成完整后预览效果 输入框内输入如下内容: 设计一个对比工具,能够模拟传统手动调试和AI辅助调试timed_out错误的过程。工具应展示两种方法的耗时、准确率和开发者体验,并提供数据支持。 在开发过程中,遇到timed_out错误是再常见不过的事情了。这类错误通常出现在网络请求、数据库连接或API调用时,由于响应时间超过预设阈值而触发。传统的处理方法和新兴的AI辅助工具在解决这类问题上展现出截然不同的效率和体验。今天,我就来分享一下两者的对比,以及我在实际项目中得到的体会。 1. 传统手动调试方法 传统方法通常依赖于开发者的经验和反复测试,耗时且容易出错。常见的步骤如下: 1. 日志分析:首先需要查看日志,定位错误发生的具体位置和上下文信息。这一步往往需要翻阅大量日志文件,耗时较长。 2. 代码审查:检查相关代码段,确认超时设置的合理性,比如网络请求的超时时间是否过短。

AI赋能原则2解读思考:从权威到机制-AI 时代的分层式信任体系

AI赋能原则2解读思考:从权威到机制-AI 时代的分层式信任体系

目录 一、AI 的“撒谎”:技术能力还是系统性风险? (一)生成式机制的幻觉性(hallucination) (二)多模态模型的构建方式导致的结构偏移 (三)任务驱动可能诱导“策略性输出” 二、在真假交织的时代:信任不再来自“权威”,而来自“机制” (一)信任的底层逻辑:从“身份可信”到“过程可信” 1. 可解释性与透明机制(Explainable AI / XAI) 2. 溯源与可验证内容(RAG + Source Attribution) 3. 系统级信号验证(Watermarking & Model Signatures) (二)超级能动性的技术化体现 三、AI“撒谎”与人类心理:信任错位引发的深层认知震荡 (一)