普通视图

发现新文章,点击刷新页面。
昨天 — 2025年9月7日首页

uni-app项目Tabbar实现切换icon动效

作者 168169
2025年9月7日 12:06

前情

不知道该说是公司对产品要求稿,还是公司喜欢作,最近接手公司的一个全新跨端(快抖微支+app)的项目,项目还没有上线就已经改了4版了,改改UI,换换皮也就算了,关键是流程也是在一直修改,最近就接到上层说这小程序UI太丑了,要重新出UI,说现在的UI只能打60分,希望UI能多玩出点花样来,于是就接到现在的需求了,UI希望实现展形Tabbar,根据不同页面主题色需要切换Tabbar的背景,还希望默认高亮选中的是Tabbar项的中间项,而且还希望实现一些icon切换动效,里面任何一条想实现都只能靠自定义 Tabbar来做了

心里虽有排斥,排斥的是修改太频率了,每次都是刚刚调通又来大调整,心态上多少有点浮动,但这就是工作吧,互相配合才能打造老板喜欢的好的产品,用户喜欢不喜欢只能靠市场验证了,我也就偷偷骂了二句娘就接着开发这一个需求了

自定义Tabbar

异常Tabbar,对于我来说不是什么大问题,因为我已经在插件市场分享了一个自定义Tabbar的组件,就是为了能快速应对这种需求,我发布在插件市场的组件地址是:ext.dcloud.net.cn/plugin?id=2…

我实现异形组件的关键代码如下

这是Tabbar的配置数据:

...
tabbar: {
  color: '#8D8E91',
  selectedColor: '#000000',
  borderStyle: 'white',
  backgroundColor: 'transparent',
  tabbarHeight: 198,
  holderHeight: 198,
  iconStyle: { width: '44rpx', height: '44rpx' },
  activeIconStyle: { width: '44rpx', height: '44rpx' },
  textStyle: { fontSize: '24rpx' },
  activeTextStyle: { fontSize: '24rpx' },
  list: [
    {
      pagePath: '/pages/discover/discover',
      iconPath: '/static/tabbarnew/fx.png',
      selectedIconPath: '/static/tabbarnew/fxactive.png',
      text: '发现',
      key: 'discover',
    },
    {
      pagePath: '/pages/games/games',
      iconPath: '/static/tabbarnew/yx.png',
      selectedIconPath: '/static/tabbarnew/yxactive.png',
      text: '游戏',
      key: 'games',
    },
    {
      pagePath: '/pages/index/index',
      iconPath: 'https://cdn.dianbayun.com/static/tabs/xwz.gif',
      selectedIconPath: 'https://cdn.dianbayun.com/static/tabs/xwzactive.gif',
      text: '新物种',
      key: 'index',
    },
    {
      pagePath: '/pages/product/product',
      iconPath: '/static/tabbarnew/sc.png',
      selectedIconPath: '/static/tabbarnew/scactive.png',
      text: '商城',
      key: 'product',
    },
    {
      pagePath: '/pages/my/my',
      iconPath: '/static/tabbarnew/wd.png',
      selectedIconPath: '/static/tabbarnew/wdactive.png',
      text: '我的',
      key: 'my',
    },
  ],
}
...

下面是导航栏组件的关键结构和一些为了实现icon切换动效的css:

<!-- CustomTabBar 组件关键代码 -->
<hbxw-tabbar 
    :config="globalInstance.tabbar" 
    :active-key="activeKey" 
    :tabbar-style="{ backgroundImage: bgType === 'black' ? 'url('黑色背景')' : 'url('白色背景')', backgroundSize: '100% auto' }"
>
    <template #default="{ item, isActive, color, selectColor, iconStyleIn, activeIconStyleIn, textStyleIn, activeTextStyleIn }">
      <view
        class="w-full flex flex-col items-center justify-center h-[134rpx] relative"
        v-if="item.key !== 'index'"
      >
        <view class="w-[44rpx] h-[44rpx] relative" :class="{'active': isActive}">
          <image
            class="w-[44rpx] h-[44rpx] absolute top-0 left-0 normal-img"
            :src="item.iconPath"
            :style="iconStyleIn"
          />
          <image
            class="w-[44rpx] h-[44rpx] absolute top-0 left-0 active-img"
            :src="item.selectedIconPath"
            :style="activeIconStyleIn"
          />
        </view>
        <text
          class="text-[24rpx]"
          :style="{ color: !isActive ? color : selectColor, ...(isActive ? activeTextStyleIn : textStyleIn) }"
        >
          {{ item.text }}
        </text>
      </view>
      <view
        class="w-full flex flex-col items-center justify-center h-[134rpx] relative"
        v-else
      >
        <view class="w-[103rpx] h-[103rpx] relative" :class="{'active': isActive}">
          <image
            class="w-[103rpx] h-[103rpx] absolute top-0 left-0 normal-img"
            :src="item.iconPath"
          />
          <image
            class="w-[103rpx] h-[103rpx] absolute top-0 left-0 active-img"
            :src="item.selectedIconPath"
          />
        </view>
      </view>
    </template>
  </hbxw-tabbar>
</template>

// 这个是为了实现icon动添加的css
<style lang="scss" scoped>
  @keyframes normalimg {
    0% {
      opacity: 1;
      transform: scale(1);
    }
    100% {
      opacity: 0;
      transform: scale(.3);
    }
  }
  @keyframes activeimg {
    0% {
      opacity: 0;
      transform: scale(.3);
    }
    100% {
      opacity: 1;
      transform: scale(1);
    }
  }
    .active-img{
    opacity: 0;
    transform: scale(.3);
  }
  .normal-img{
    opacity: 1;
    transform: scale(1);
  }
  .active {
    .normal-img{
      animation: normalimg 0.4s ease-in-out 0s forwards;
    }
    .active-img{
      animation: activeimg 0.4s ease-in-out 0.4s forwards;
    }
  }   
</style>

注:当前项目我使用了Tainwind CSS原子化CSS框架来书写样式

在页面上使用的代码如下:

<!-- 这是首页的页面Tabbar 高亮index项,同时背景用黑色 -->
<CustomTabBar activeKey="index" bgType="black" />

其实原理很简单,因为我的发布在应用市场的组件有提供 slot,你可以自由定义Tabbar的每一项的结构样式,我这里的做法就是中间项单独一块结构来实现异形效果,实现后的效果如下:

image.png

坑位?

展开tabbar效果是好实现的,但是在实现Tabbar切换icon动效的时候,我遇到了麻烦,小程序虽然有提供专门用于做动画的API,但是我个人不太喜欢用,我比较喜欢使用css3实现动画,使用上更简单的同时,动画流畅度也优于JS来做

因为是切换动效,首先想到的就是通过transition来实现,通过给父组添加一个active的类名控制下面icon的来实现切换动效,这是实现状态变化动效的首选,但是发现完全没有用,一度怀疑是不是小程序不支持transition,于是想到换方案,我通过aniamtion来实现动效,确实是有效果的,但是只有首次切换tabbar的时候有效果

Why?

我一开始是怀疑是不是小程序对于css3动画有兼容性问题,或者是支付宝不支持动效,因为我此时正在开发的就是支付宝端,也去小程序论坛逛了逛 ,确实有一些帖子说到transition在小程序上兼容问题,也问了AI,AI也说是有,而且不现标签组件可能支持的transition还不一样,此时我陷入了怀疑,难道真的要靠JS来实现么,但是以我的个人开发经验,我不止在一个小程序项目中使用过css3来实现动效,都是没有问题的,在经过一段时间的思考我,我突然意识到一个问题,动画没出现真的不是兼容性的问题,而是没有动效或者只有首次有这根本就是正常现象

transition没有是因为当你切换tabbar的时候整个组件是重新渲染的,对于初次渲染的元素你是没法使用transition的,至于为什么后面点也都没有,是我在尝试 animation的时候发现它只有首次点击切换的时候才有我才突然意识到,因为这是tabbar啊,小程序是有会缓存的,你显示一次后,小程序页面会运行在后台,你再次切换的时候只是激活而已,根本不会有样式的变化

解决方案

既然Tabbar切换页在不会重新从0渲染,只是显示与隐藏而已,那我们就手动的让它来实现Tabbar的高亮样式切换即可,虽然Tabbar切换页面不会重新渲染,但是它会触发二个小程序的生命钩子onShow/onHide,那我们就从这二处着手,因为是多个页面要复用,我此处抽了hooks,关键代码如下:

import { onShow, onLoad, onHide } from '@dcloudio/uni-app'
import { ref } from 'vue'

export const usePageTabbar = (type) => {
  const activeType = ref('')
  onLoad(() => {
    uni.hideTabBar()
    activeType.value = type
  })

  onShow(() => {
    activeType.value = type
    uni.hideTabBar()
  })

  onHide(() => {
    activeType.value = ''
    uni.showTabBar()
  })

  return {
    activeType
  }
}

页面上使用也做了调整,关键代码如下:

<script setup>
    ...
    import { usePageTabbar } from '@/hooks/pagesTabbar'

    const { activeType } = usePageTabbar('index')
    ...
</script>

<template>
        ...
        <!-- 页面tabbar -->
    <CustomTabBar :activeKey="activeType" />
    ...
</template>

至此完成了这一次的 tabbar大改造,实现的效果如下:

20250906_201121.gif

其实此时再切换回用transition去做动画,这也是可以的,只是我后面已经用 animaltion实现了就懒得改它了

思考

对于做开么的我们,平时抽取一些可以复用的组件并分享真的是值得做的一件事,它可以在很多时候帮你提高开发速度,同时也减少了你反复的写一些重复代码

对于需求调整这是很多开发都不喜欢的事,因为当项目需求调整的过多,原来已经快接近屎山的代码更加加还变成屎山,但是这个对于一些小公司开发流程不是特别规范的需求调整是不可避免的,我们无需过多烦恼,只要项目进度允许,他们要调就让他调吧,相信大家都是为了打造一款精品应用在使劲而已,何乐而不为了

个人的能力和认识都有限,对于一个问题的解决方案有很多种,我上面的实现方案并不一定最好的,如果你有更好的解决方案,欢迎不吝分享,一起学习一起进步

昨天以前首页

uniapp

作者 金州_拉文
2025年9月4日 23:10

一、各端适配机制

uni-app的适配机制是一个多层次、多维度的系统,其核心目标是一套代码多端发布。为了实现这个目标,它采用了以下几种关键的适配机制:

1、框架层编译时适配(最核心)

这是uni-app最根本的适配机制,你编写的Vue组件和JS API在编译时会转成不同平台的支持格式。

组件转换
view组件
  • 编译到H5端时,会被转成div
  • 编译到微信小程序端时,会被转成view(小程序原生组件)
  • 编译到APP端时,会被转成div 这个过程对开发者是透明的,无需关心,只需要使用uni-app提供的统一标准和API即可

2、样式响应式 rpx(响应式像素)

rpx是uni-app为解决不同屏幕尺寸适配而提出的核心单位

  • 原理:以750px宽的设计稿为基准,规定屏幕总宽度为750rpx。例如:在设计稿上一个100px宽的元素转换成样式就是 width:100rpx
  • 计算方式:在一个宽度为375px的物理屏幕上 1rpx = (375物理像素/750)= 0.5px。所以100rpx在这个屏幕上就是50px。在一个宽度为750px的物理屏幕上:1rpx = 1px 100rpx = 100px
  • 优点:元素的宽度会随着屏幕的宽度等比缩放,极大简化了移动端的适配工作。
  • 主要:在APP和小程序端 rpx的实现非常完美,在H5端其转换依赖于html元素的font-size,可能会受到浏览器的默认样式和第三方CSS库的影响,需要主要检查。

条件编译(解决非共性的问题)

当某个功能只能在特定的平台实现或者在不同平台需要不同实现时,就用到了条件编译

  • 语法:  使用 #ifdef(if defined) 或 #ifndef(if not defined) + 平台名称 作为注释符号。
  • 应用范围:  可以用于 JS、CSS、模板、pages.json 甚至 manifest.json

二、跨端兼容性处理方案

尽管有上述强大的适配机制,但在实际的开发过程中,仍然会遇到兼容性问题,处理这些问题有一套成熟的方法论

1、API兼容性判断

  • 运行时判断平台:使用 uni.getSystemInfoSync().platform动态获取当前运行平台,然后执行不同逻辑。 javascript
const platform = uni.getSystemInfoSync().platform;
if (platform === 'android') {
  // 安卓特殊逻辑
} else if (platform === 'ios') {
  // iOS特殊逻辑
}
  • API存在性判断:在使用一个可能不存在的API先判断它是否存在 javascript
if (typeof uni.requireNativePlugin !== 'undefined') {
  // 只有App端才存在这个方法,安全地使用它
  const module = uni.requireNativePlugin('SomeNativeModule');
}

2、组件兼容性处理

  • 使用官方通用组件:优先使用uni-app提供的跨端通用组件(如:uni-list、uni-icons)
  • 条件编译创建不同组件:对于差异巨大的组件使用条件编译为不同平台编写不同的模板结构

3、样式兼容性处理

  • 使用rpx进行布局:这是首先的布局单位
  • 使用Flex布局:Flex布局在各端支持度最好,表现最一致
  • 主要默认样式:不同平台(尤其是H5端浏览器)的默认样式,推荐在App.vue中引入重置样式

4、遵循优雅降级原则

在设计功能时,优先考虑所以平台都能实现的基础方案,然后再为高级平台(如APP端)通过条件编译增强体验。

🔥 太全面啦!99% 开发者可能都会遇到的 uView Pro 组件库问题 - 总结篇

2025年9月1日 17:16

推荐阅读:

# uView Pro 正式开源!70+ Vue3 组件重构完成,uni-app 组件库新晋之星

# uView Pro 全新升级来啦!一行配置,解锁 VSCode 全局 TS 类型提示与校验

# 2025 最推荐的 uni-app 技术栈:unibest + uView Pro 高效开发全攻略

# 近期 Star 飙升!uView Pro 文档也开源啦:完全免费、无广告、高效上手

本文综合社区反馈与官方文档,系统梳理了使用 uView Pro 组件库开发 uni-app 应用时的常见问题、解决方案及最佳实践,帮助大家高效避坑、提升项目质量。

本文会持续更新一些常见问题及解决方案


一、uView Pro 开源简介

Snipaste_2025-08-27_20-01-01.png

uView Pro 是基于 uni-app + Vue3 + TypeScript 全面重构的高质量组件库,内置 70+ 常用 UI 组件,支持多端适配、主题定制、TS 类型提示、Volar 智能补全等特性。其开源、活跃、文档完善,目前已逐步成为 uni-app 生态主流选择之一了。

  • 开源地址

uView Pro 开源地址:

  • 技术栈:Vue3 + TS + Vite + uni-app
  • 适用场景:H5、小程序、App、快应用等全端开发

1.gif


快速集成步骤:

uView Pro 支持 npmuni_modules 两种主流安装方式,配置方式高度一致。无论采用哪种方式,均可通过 easycom 实现组件自动引入,极大提升开发效率。

以下为统一的配置说明:

1. 安装 uView Pro

  • npm 安装:
npm install uview-pro
# 或
yarn add uview-pro
# 或
pnpm add uview-pro
  • uni_modules 安装:

通过 HBuilderX 插件市场或手动下载,将 uView Pro 放入 uni_modules 目录。

插件市场:https://ext.dcloud.net.cn/plugin?id=24633

2. 引入 uView Pro 主库

main.ts 中引入并注册 uView Pro:

import { createSSRApp } from 'vue';
// npm 方式
import uViewPro from 'uview-pro';
// uni_modules 方式
// import uViewPro from "@/uni_modules/uview-pro";

export function createApp() {
    const app = createSSRApp(App);
    app.use(uViewPro);
    return {
        app
    };
}

3. 引入全局样式

uni.scss 中引入主题样式:

/* npm 方式 */
@import 'uview-pro/theme.scss';
/* uni_modules 方式 */
/* @import "@/uni_modules/uview-pro/theme.scss"; */

App.vue 首行引入基础样式:

<style lang="scss">
  /* npm 方式 */
  @import "uview-pro/index.scss";
  /* uni_modules 方式 */
  /* @import "@/uni_modules/uview-pro/index.scss"; */
</style>

4. 配置 easycom 自动引入组件

pages.json 中配置 easycom 规则,实现组件自动引入:

{
    "easycom": {
        "autoscan": true,
        "custom": {
            // npm 方式
            "^u-(.*)": "uview-pro/components/u-$1/u-$1.vue"
            // uni_modules 方式
            // "^u-(.*)": "@/uni_modules/uview-pro/components/u-$1/u-$1.vue"
        }
    },
    "pages": []
}

温馨提示

  • 1.修改 easycom 规则后需重启 HBuilderX 或重新编译项目。
  • 2.请确保 pages.json 中只有一个 easycom 字段,否则请自行合并多个规则。
  • 3.一定要放在 custom 内,否则无效。

5. Volar 类型提示支持

如需在 CLI 项目中获得 Volar 的全局类型提示,请在 tsconfig.json 中添加:

{
    "compilerOptions": {
        // npm 方式
        "types": ["uview-pro/types"]
        // uni_modules 方式
        // "types": ["@/uni_modules/uview-pro/types"]
    }
}

HBuilderX 项目暂不支持 tsconfig.jsontypes 配置,CLI 项目推荐配置以获得最佳 TS 体验。

1.gif

6. 组件使用

配置完成后,无需 importcomponents 注册,可直接在 SFC 中使用 uView Pro 组件:

<template>
    <u-button type="primary">按钮</u-button>
</template>

请通过快速上手了解更详细的内容!

二、常见问题与解决方案

以下总结梳理了使用 uView Pro 组件库开发 uni-app 应用时的常见问题、解决方案及最佳实践,帮助大家高效避坑、提升项目质量。

1. 组件无法正常显示/样式错乱

image.png

原因分析

  • 未正确引入 uView Pro 组件库或样式
  • easycom 配置缺失或路径错误
  • 组件名拼写错误

解决方案

  • 按官方文档配置 easycom,推荐使用自动引入:
    // pages.json
    "easycom": {
      "autoscan": true,
      "custom": {
        "^u-(.*)": "@/uni_modules/uview-pro/components/u-$1/u-$1.vue"
      }
  • 确认 main.ts 已全局引入 uView Pro
  • 检查组件名、路径拼写,建议复制粘贴官方示例
  • 如样式异常,检查 uview-pro/theme.scss 是否全局引入,检查uview-pro/index.scss 是否引入
  • 检查 easycom 配置是否正确

2. npm 与 uni_modules 安装混用导致依赖冲突

原因分析

  • 同时存在 npm 安装和 uni_modules 方式,依赖重复
  • 依赖版本不一致,导致打包异常

解决方案

  • 推荐二选一:npm 安装(CLI 项目)uni_modules 安装(HBuilderX 项目)
  • 清理无用依赖,保持依赖唯一性
  • 升级至最新版本,避免历史 bug

最佳实践

  • CLI 项目优先使用 npm 安装,便于版本管理与类型提示
  • HBuilderX 项目优先使用 uni_modules,兼容性更好

3. Volar/TypeScript 类型提示缺失

原因分析

  • tsconfig.json 未正确配置 types/typeRoots
  • VSCode 未安装 Volar 或未禁用 Vetur
  • uView Pro 版本过旧

解决方案

  • CLI 项目在 tsconfig.json 添加:
    {
      "compilerOptions": {
        "types": ["uview-pro/types"]
      }
    }
    
  • uni_modules 方式一般无需配置,如无提示可补充 typeRoots
  • 确认 VSCode 仅启用 Volar 插件
  • 升级 uView Pro 至最新版
  • 重启 VSCode

效果示例

  • 组件标签、属性、事件、插槽等均有智能补全与类型校验

2.png

3.png

4.png

1.gif


4. 组件属性报错无提示

Snipaste_2025-09-01_13-29-29.png

原因分析

  • 组件名、属性名拼写错误
  • 未正确配置类型声明
  • 依赖未升级

解决方案

  • 检查拼写,参考官方文档
  • 按类型声明配置 tsconfig.json
  • 升级依赖

最佳实践

  • 推荐 <script setup lang="ts"> 书写,享受最完整类型推断
  • 善用 IDE 跳转、补全、错误提示

Snipaste_2025-09-01_13-25-42.png


5. 工具函数类型提示与 tree-shaking

问题表现

  • 工具函数类型提示缺失
  • 打包体积大

解决方案

  • 推荐按需导入工具函数,自动 tree-shaking
    import { deepClone } from "uview-pro";
    const copy = deepClone(obj); // 类型自动推断
    
  • 也可通过 uuni.u 或 uni.u 访问

最佳实践

  • 按需导入优先,减少打包体积
  • 充分利用类型提示提升开发效率

6. HBuilderX 项目类型提示支持不足

问题表现

  • HBuilderX 下类型提示不全或无效

解决方案

  • HBuilderX 暂不支持 tsconfig.json types 配置,建议 CLI 项目开发获得最佳 TS 体验
  • 如需类型提示,尝试手动补充 typeRoots

7. 组件未识别/打包异常/运行报错

原因分析

  • 组件未注册、路径错误、依赖冲突
  • 低版本 uni-app/依赖包

解决方案

  • 检查组件注册与路径
  • 升级 uni-app 及相关依赖
  • 清理 node_modules/uni_modules 重新安装

8. 主题定制与全局样式冲突

问题表现

  • 主题色、全局样式被覆盖或冲突

解决方案

  • 按官方文档引入并覆盖 theme.scss
  • 避免全局样式污染,合理使用作用域
  • 主题变量建议统一管理

9. 与其他组件库(如 uview-plus 等)引入冲突

image.png

image.png

问题表现

  • 组件样式错乱、功能异常、控制台报错
  • 组件名、全局样式、工具函数等冲突

原因分析

  • 同时引入多个同名或类似命名空间的组件库(如 uview-plus、uView2.x、colorui 等)
  • easycom 规则、全局样式、工具函数命名冲突

解决方案

  • 尽量避免同一项目中同时引入多个同类组件库,尤其是命名空间重叠的库
  • 如需迁移,建议逐步替换为 uView Pro,清理旧依赖和 easycom 配置
  • 检查 easycom custom 规则,确保只指向 uView Pro 目录
  • 检查全局样式、工具函数命名,避免覆盖
  • 如必须共存,建议手动引入组件并区分命名,避免自动扫描

最佳实践

  • 项目初期统一组件库选型,避免后期大规模迁移
  • 团队协作时明确依赖规范,定期代码审查

10. 使用 Sass 时语法不对引起的 bug

image.png

问题表现

  • 编译报错、样式丢失、部分组件样式异常
  • 控制台提示 Sass 语法错误或不兼容

原因分析

  • Sass 语法与 loader 版本不兼容(如新版 Sass 不再支持 @import、部分语法变更)
  • sass、sass-loader 版本过高或过低,导致编译异常
  • 未锁定依赖版本,团队成员环境不一致

解决方案

  • 推荐统一并锁定依赖版本:

    "sass": "1.63.2",
    "sass-loader": "10.4.1"
    
  • 如遇到语法报错,优先检查 loader 版本与官方文档

  • 团队协作时,建议在 package.json 中锁定依赖,避免自动升级

  • 删除 node_modules 并重新安装依赖,确保环境一致

最佳实践

  • 定期关注 uView Pro 官方和 Sass 官方的兼容性公告
  • 统一团队开发环境,避免“我的能编译你的不能”问题

三、最佳实践总结

  1. 规范依赖管理:npm/uni_modules 二选一,保持依赖唯一性。
  2. 优先使用 CLI + npm + Volar + TS,获得最佳开发体验。
  3. 全局配置 easycom 与样式,组件即用即引。
  4. 充分利用类型提示与 IDE 能力,减少低级错误。
  5. 按需导入工具函数,优化打包体积。
  6. 定期升级依赖,关注官方 changelog 与 issue。
  7. 遇到问题多查文档/issue,善用社区资源。
  8. 团队协作时统一配置与代码规范,提升协作效率。

四、常见问题排查清单

  • 组件/样式未生效?→ 检查 easycom、样式引入、依赖版本
  • 类型提示无效?→ 检查 tsconfig.json、Volar 插件、依赖版本
  • 组件/工具函数报错?→ 检查拼写、注册、依赖冲突
  • 打包异常?→ 清理 node_modules/uni_modules,重新安装
  • 主题/全局样式冲突?→ 检查 theme.scss 引入与变量覆盖

五、总结

uView Pro 作为 uni-app 生态的新星组件库,凭借完善的 TS 类型支持、丰富的组件体系和活跃的社区生态,极大提升了多端开发效率。只要遵循本文最佳实践与排查清单,大部分常见问题都能高效解决。

官方资源

如有更多问题,欢迎在官方 issue 区留言或加入交流群反馈!


本文根据实际项目补充,内容持续更新,欢迎 Star、Fork、PR、Issue 支持与反馈。

苹果市场常见的处罚邮件,最低处罚基本上听劝稳过。

作者 iOS研究院
2025年9月1日 11:07

背景

对第一次接触AppStore的新手来说,收到AppStore的通知邮件就会慌张的一批。其实大可不必担心,除了3.2f之外,其他的都是和开发者友好的协商。只是语气看起来有点恐吓感,动不动就封号警告。

新手村警告

位列最低级等级的警告,其实就是11.2,就是苹果检查到了异常流量行为。比如:刷评论、刷下载。

这种情况需要自查、自测,不要继续顶风作案,大多数没有太大问题

初级警告

初级警告一般内容都为14天整改,但是AppStore的产品是在线状态。简单来说就是问题不大,但是需要对现有功能产品进行说明。

常见的主要是内购问题,原文大致为:AppStore认为当前服务的定价过高,与市场上其他同类型产品相比没有发现其他更具特色的内容。

这种情况,可以用足够的内容支撑自己的产品符合当前的定价。PUA苹果,连迭代都不用亦可过审

当然也可以通过改价格,以退为进。

中级警告

相对于中级警告而言,产品也还在线。宽限时间一般为30天,但是30天不解决会下架。这种场景的一般为App存在争议问题或者遭遇了同行举报。

苹果需要开发者提供能够证明自己产品所属权的内容,确保争议问题得到解决。

高级警告

在高级警告段位,最常见的就是3.2f。这种情况就是产品已下架,账号待终止状态。一般3.2f各有各的不同,至于能不能解封救回,全看犯的事儿严不严重。

对于能够解释清楚的产品来说,就是取保候审

对于AB面这种产品,就是等嘎的状态。基本上无力回天。

终极警告

之所以叫终极警告是因为一但收到这类邮件,对不起,斩立决!

只要3.2f并且在邮件内容没有提及申诉期的时间,那么不用折腾了,基本可以重开了别无他法!

死亡邮件.jpeg

看到这段话的时候,基本上不用来咨询了。除非你和库克或者乔布斯有点关系,不然没卵用了的。

遵守规则,方得长治久安,最后祝大家大吉大利,今晚过审!

相关推荐

# 苹果开发者续费大坑及成功续费方案!亲测有效

# Pingpong和连连的平替,让AppStore收款无需新增持有人。

# 苹果加急审核是“绿色通道”还是“死亡陷阱”?

# 苹果开发者邮箱,突然收到11.2通知严重么?

# 不想被苹果卡审最好错开这两个提审时间

# 手撕苹果审核4.3是代码问题还是设计问题?

# 有幸和Appstore审核人员进行了一场视频会议特此记录。

知识星球

更多Appstore咨询问题,请关注知识星球【iOS研究院】。「提供1v1上架指导,帮助开发者解决Appstore的疑难杂症,助力每一位开发者!」

江湖传闻谷歌比苹果严格多了,那么到底有多狠?

作者 iOS研究院
2025年8月27日 17:56

背景

对于独立开发者来说,能够降低成本快速测试结果的。除了Appstore就只有谷歌play。

但是,谷歌play对于国内已经严防死守。主要是因为国人小聪明太多,马甲套壳在规则的边缘疯狂试探。

这就导致了谷歌play对于国内采取了一刀切政策。

注册成本

对于Appstore99美刀的入门价来说,谷歌开发者相对便宜很多。

只需要25美刀,基本上可以说是良心价了。

审核成本

简单来说:基本上中国大陆区提交的代码,入网必死。今年已经测试了6个谷歌账号,不管是公司还是个人都是直接暴毙。

谷歌play最为严重的打击方式就是直接封号,比Appstore的策略更加简单粗暴。

基本上从提交到审核,耗时三天,然后直接封号。

谷歌play直接从代码、网关等多个维度校验开发者的真实性。主打一个严防死守

审核策略

Appstore审核基本上对于内测没有必要要求,但是谷歌play截然不同。

针对个人开发者,必须要有20个账号完成内部封闭测试15天,才可以正式提交审核。 如果说用来测试的账号,之前被封号过,那么反手就是封号大礼包。

对于公司账号则没有这种苛刻的条件限制。

先出海的享福,后出海的遭殃。

在前辈不断地试探下,不管是Appstore还是谷歌play,审核力度都会进步一步升级。如果打擦边球的方式,基本上注定死路一条。

所以合规化才是可持续发展的必经之路。不管是Appstore还是谷歌play,已经上车的请把握好自己的方向,要拎的清楚吃一顿,还是吃顿顿

遵守规则,方得长治久安,最后祝大家大吉大利,今晚过审!

相关推荐

# 苹果开发者续费大坑及成功续费方案!亲测有效

# Pingpong和连连的平替,让AppStore收款无需新增持有人。

# 苹果加急审核是“绿色通道”还是“死亡陷阱”?

# 苹果开发者邮箱,突然收到11.2通知严重么?

# 不想被苹果卡审最好错开这两个提审时间

# 手撕苹果审核4.3是代码问题还是设计问题?

# 有幸和Appstore审核人员进行了一场视频会议特此记录。

知识星球

更多Appstore咨询问题,请关注知识星球。「提供1v1上架指导,帮助开发者解决Appstore的疑难杂症,助力每一位开发者!」

三年期已满,你的产品不再更新将于90天后下架。

作者 iOS研究院
2025年8月18日 10:54

背景

对Appstore来说,多久不更新有风险一直是一个待定的事情,说几年的都有。

恰巧昨天帮之前公司的老板解决问题,看到App提示有未解决的小红点,于是便看到了如下内容:

苹果通知原文.jpg

简单来说:

苹果从16年会把年久失更的产品判定为僵尸产品。

核心:由于这款应用在过去三年内没有更新过,也没有达到最低下载门槛,它将在90天内从app Store下架。我们要求您尽快提交应用程序更新。

所以,对于无法更新的产品【比如4.3产品或资质问题】,要合理的保证自己现有产品数据的稳定性和下载量,避免因为下载量过低,触发强更条款,陷入更加被动的局面。

遵守规则,方得长治久安,最后祝大家大吉大利,今晚过审!

相关推荐

# 苹果开发者续费大坑及成功续费方案!亲测有效

# Pingpong和连连的平替,让AppStore收款无需新增持有人。

# 苹果加急审核是“绿色通道”还是“死亡陷阱”?

# 苹果开发者邮箱,突然收到11.2通知严重么?

# 不想被苹果卡审最好错开这两个提审时间

# 手撕苹果审核4.3是代码问题还是设计问题?

# 有幸和Appstore审核人员进行了一场视频会议特此记录。

苹果审核被拒要听劝,能沟通回复解决真的不用改!

作者 iOS研究院
2025年8月13日 09:50

背景

由于苹果审核最后一步是人工介入,所以这也大大增加了影响审核结果的不确定。

比如最近有一个同行,本来是iPhone设备的产品,应是被苹果因为不适配iPad被打回。

Guideline 4.0 - Design  
  
Several screens of the app were crowded, laid out, or displayed in a way that made it difficult to use the app when reviewed on iPad Air 11-inch (M2) running iPadOS 18.6.  
  
Next Steps  
  
To resolve this issue, revise the app to ensure that the content and controls on the screen are easy to read and interact with.  
  
Note that users expect apps they download to function on all the devices where they are available. Since your app may be downloaded onto iPad devices, it is important that it also function as expected for iPad users.

简单来说:

苹果认为该应用会被安装在iPad类型的设备中,期望UI可适配iPad上的所有情况。

但,离谱的是苹果只是提出页面不适配,感到了拥挤并没有明确说明,具体是哪些页面。

正常来讲附件会有对应的应用截图,实际上并没有任何参考。

自查阶段

  1. 构建勾选情况,如果勾选了iPad构建的版本,除了本身要兼容iPhone还必须要兼容iPad,而且在市场截图还必须对应配置。

构建版本.png

  1. 使用iPad自查页面,确保产品本身确实没有审核员所说的适配问题

快速解决方案

由于该同行仅仅只是勾选了iPhone尺寸,并不会做iPad的兼容。同时,该产品已经顺利迭代过3~4次,并非首次提交。所以,用最简单直接的方式向苹果主动说明并且做一个保证

回复内容:
苹果审核:
   你好,感谢你的提醒。我们的产品并没有iPad建构的规划,并且我们保证在后续的迭代中,都并不会为
iPad的用户提供服务。我们在之前的迭代中都没有遇到此类问题,并且我们确保在项目构建未勾选iPad相关
配置,所以我们不清楚为什么一定适配iPad所有场景?
最好的问候

对话截图.jpeg

遵守规则,方得长治久安,最后祝大家大吉大利,今晚过审!

相关推荐

# Pingpong和连连的平替,让AppStore收款无需新增持有人。

# 苹果加急审核是“绿色通道”还是“死亡陷阱”?

# 苹果开发者邮箱,突然收到11.2通知严重么?

# 不想被苹果卡审最好错开这两个提审时间

# 手撕苹果审核4.3是代码问题还是设计问题?

# 有幸和Appstore审核人员进行了一场视频会议特此记录。

知识星球

更多Appstore咨询问题,请关注知识星球。「提供1v1上架指导,帮助开发者解决Appstore的疑难杂症,助力每一位开发者!」

成年人的沟通,不谈钱谈什么?谈感情?

作者 iOS研究院
2025年8月12日 11:56

背景

正所谓,男人不好色好什么?How are you 么?

表情包.png

本来今天准备了另外的一个素材,准备发稿了。突然有个xxv加我,看着头像就知道不一般,结果果然不一般。

对话截图

对话截图.png

为啥三个不?

首先,我要表明自身立场确实在不方便接语音。其次,遇到的白嫖党太多了习惯了。所以,我习惯丑话说前边。

本质上成年人的社交,本来就应该是高效的。如果愿意付费就聊聊,不愿意付费就算了,没必要浪费彼此的时间

毕竟大家的时间都挺值钱,没必要互相耽误

对于这样就别做生意了那就更可笑了,你在教我做事?

我用了最简单的三个不,就是为了过滤这种低价低质量的交流。

同时,再次声明一下。我从16年就开始从事iOS开发的工作,从20年iOS审核过审严格之后截至目前,已经累计折损了60个账号。这里边有部分是公司,有部分是个人试错。

公众号咨询只不过是把之前账号成本回回血,顺便真正帮助一些想上架却上不去的同行。

有独立开发者身份傍身,即使不做咨询也依旧可以很潇洒。因为自身暂时没有什么好的产品,而且工具类产品暂时也不需要维护。

所以找了个公司混混社保,让自己时刻保持着学习的状态,在结交一些新的志同道合的朋友,拓展一下自己的人脉圈子。

写在最后

大家都是成年人别总想着像小孩子一样占便宜了。成人的免费往往都是最贵的,比如免费领鸡蛋,高价卖保jian品。再比如免费陪聊,引入杀🐷盘。

最近还看到一个见闻,易水寒一套时装10w+,而大多数游戏还停留在6元首冲的套路。

所以,与其做低价低质量的用户,不如分流提高客单价。以少胜多,以质取胜。

遵守规则,方得长治久安,最后祝大家大吉大利,今晚过审!

相关推荐

# Pingpong和连连的平替,让AppStore收款无需新增持有人。

# 苹果加急审核是“绿色通道”还是“死亡陷阱”?

# 苹果开发者邮箱,突然收到11.2通知严重么?

# 不想被苹果卡审最好错开这两个提审时间

# 手撕苹果审核4.3是代码问题还是设计问题?

# 有幸和Appstore审核人员进行了一场视频会议特此记录。

知识星球

更多Appstore咨询问题,请关注知识星球。「提供1v1上架指导,帮助开发者解决Appstore的疑难杂症,助力每一位开发者!」

纯粹的广告变现,已经来到了山穷水尽的地步

作者 iOS研究院
2025年8月11日 11:23

背景

各大广告平台在7月17号,开启了SDK版本的重大升级。以穿山甲为例:站内信也在多次提醒,请将SDK版本升级到最新版本。

其实从7月15号开始,广告点击率已经有了明显的风控,从15号~17号,点击率从两位数变个位数。足以预见未来广告收益的波动将会迎来,多么严峻的暴风雨。

ecpm.png

整治重点

针对恶意的广告App,随意跳转第三方应用的问题,进行了针对性打击。

同时,整改关于误触堆出来的曝光和点击率

带来的影响?

以开屏广告为例,ecpm从40元左右下降到了20元左右,基本上可以说是腰斩。

作为变现作为核心的激励视频和插屏广告,也大相径庭。单用户产生收益从人均0.18元,锐减到0.055元。

是的,没有看错。靠单一广告变现,且恶意堆砌曝光广告的路子终将落幕。

对于产品商业化的发展和规划,需要有更多的反思。每一次洗牌的背后,都是对于竞品的肃清。

如何转型?

单一的广告依然鸡肋,建议更多的开发者应该把心思放在让用户,玩的简单,用的舒服,体验较好。同时,确实帮助用户解决了生活所需的痛点。

就当下的环境而言,其实大多数用户是很愿意为自己的情绪价值买单,越来越多的人开始尊重知识付费。

所以,弱化广告变现,提升会员权益,将是未来产品发展不可或缺的生命力。

遵守规则,方得长治久安,最后祝大家大吉大利,今晚过审!

相关推荐

# Pingpong和连连的平替,让AppStore收款无需新增持有人。

# 苹果加急审核是“绿色通道”还是“死亡陷阱”?

# 苹果开发者邮箱,突然收到11.2通知严重么?

# 不想被苹果卡审最好错开这两个提审时间

# 手撕苹果审核4.3是代码问题还是设计问题?

# 有幸和Appstore审核人员进行了一场视频会议特此记录。

知识星球

更多Appstore咨询问题,请关注知识星球。「提供1v1上架指导,帮助开发者解决Appstore的疑难杂症,助力每一位开发者!」

❌
❌