طراحی اپلیکیشن iOS یعنی ساختن اپی برای آیفون و آیپد که با منطق، ژست‌ها و انتظارات کاربران اکوسیستم اپل هماهنگ باشد؛ از ناوبری و تایپوگرافی گرفته تا مجوزهای حریم خصوصی و شیوه‌ی انتشار. در ایران این کار یک لایه‌ی اضافه هم دارد: چون دسترسی مستقیم به اپ‌استور محدود است، باید از همان روز اول درباره‌ی مسیر رساندن اپ به دست کاربر تصمیم گرفت.
در این راهنما، از نگاه تیم طراحی و توسعه‌ی دییر، اصول کلیدی طراحی اپلیکیشن آیفون را مرور می‌کنیم: راهنمای رابط انسانی اپل (Human Interface Guidelines)، الگوهای ناوبری، SF Symbols، Dynamic Type، ناحیه‌ی امن، ژست‌ها و پیام‌های دسترسی. بعد سراغ واقعیت توزیع در ایران و انتخاب بین Swift و فناوری‌های چندسکویی می‌رویم. اگر دنبال اصول عمومی رابط موبایل هستید، پیشنهاد می‌کنیم ابتدا راهنمای طراحی رابط کاربری اپلیکیشن موبایل را بخوانید؛ این مقاله روی جزئیات مخصوص iOS تمرکز دارد.
طراحی اپلیکیشن iOS چه تفاوتی با طراحی اپ اندروید دارد؟
در نگاه اول هر دو اپ صفحه‌ی لمسی، دکمه و فهرست دارند، اما کاربر آیفون سال‌ها با رفتارهای مشخصی خو گرفته است: برگشتن با کشیدن انگشت از لبه‌ی صفحه، نوار تب در پایین، عنوان‌های بزرگ بالای صفحه و برگه‌هایی (Sheet) که از پایین بالا می‌آیند. اپی که این قراردادها را نادیده بگیرد، حتی اگر زیبا باشد، برای کاربر iOS «غریبه» به نظر می‌رسد و یادگیری‌اش سخت‌تر است.
تفاوت دوم در یکدستی سخت‌افزار است. تنوع دستگاه‌های اپل نسبت به اندروید محدودتر است، پس طراح می‌تواند دقیق‌تر برای اندازه‌های مشخص، ناحیه‌ی جزیره‌ی پویا (Dynamic Island) و نشانگر خانه برنامه‌ریزی کند. در عوض، اپل در بازبینی اپ‌ها و رعایت حریم خصوصی سخت‌گیرتر است و بسیاری از تصمیم‌های طراحی، مثل زمان درخواست دسترسی به دوربین یا موقعیت مکانی، مستقیماً روی پذیرش یا رد اپ اثر می‌گذارند.
خلاصه اینکه ناوبری، تایپوگرافی (فونت San Francisco در برابر Roboto)، کتابخانه‌ی آیکون (SF Symbols در برابر Material Symbols)، ظاهر کنترل‌ها و مسیر انتشار در دو سکو متفاوت است و طرح iOS باید از ابتدا با همین تفاوت‌ها ساخته شود.
Human Interface Guidelines؛ اصولی که باید از آن شروع کرد
راهنمای رابط انسانی اپل (HIG) مرجع رسمی طراحی برای همه‌ی سکوهای اپل است. این سند فهرست قوانین خشک نیست؛ مجموعه‌ای از اصول و الگوهاست که توضیح می‌دهد هر جزء کجا و چرا استفاده می‌شود. ظاهر سیستم بارها به‌روز شده، از جمله با زبان بصری Liquid Glass در iOS 26، اما اصول پایه ثابت مانده‌اند:
- وضوح (Clarity): متن خوانا، آیکون دقیق و سلسله‌مراتب روشن؛ کاربر باید بدون فکر کردن بفهمد کجاست و چه کاری می‌تواند بکند.
- احترام به محتوا (Deference): رابط در خدمت محتواست. سایه، رنگ و افکت تزئینی نباید از خود محتوا مهم‌تر شوند.
- عمق (Depth): لایه‌ها، انیمیشن‌های انتقال و برگه‌ها به کاربر می‌گویند در کدام سطح از اپ قرار دارد و چطور برگردد.
- سازگاری: استفاده از کنترل‌ها و الگوهای بومی تا جایی که ممکن است؛ سفارشی‌سازی فقط وقتی که واقعاً ارزش اضافه کند.
ما در دییر پیش از طراحی هر صفحه‌ی iOS بررسی می‌کنیم که آیا جزء بومی معادلی برای آن وجود دارد یا نه. کنترل‌های بومی به‌طور خودکار حالت تاریک، Dynamic Type، VoiceOver و تغییرات نسخه‌های بعدی iOS را پشتیبانی می‌کنند؛ جزء سفارشی همه‌ی این‌ها را باید از صفر بسازد و نگه دارد.
کدام الگوی ناوبری برای اپلیکیشن آیفون مناسب است؟
ناوبری ستون فقرات هر اپ است و در iOS سه الگوی اصلی دارد که معمولاً ترکیبی از آن‌ها استفاده می‌شود. انتخاب درست به معماری اطلاعات محصول برمی‌گردد: اول باید بدانید بخش‌های اصلی اپ چیست و کاربر چقدر بینشان جابه‌جا می‌شود.
| الگو | کاربرد اصلی | نکته‌ی طراحی |
|---|---|---|
| نوار تب (Tab Bar) | جابه‌جایی بین ۳ تا ۵ بخش هم‌سطح و پرکاربرد | همیشه در پایین دیده شود؛ برای عمل‌هایی مثل «ارسال» یا «حذف» به کار نرود |
| ناوبری سلسله‌مراتبی (Navigation Stack) | رفتن از فهرست به جزئیات و عمیق‌تر | عنوان صفحه و دکمه‌ی برگشت واضح؛ ژست کشیدن از لبه برای برگشت حفظ شود |
| برگه و نمایش مُدال (Sheet / Modal) | کار مستقل و کوتاه مثل نوشتن، فیلتر یا پرداخت | دکمه‌ی «انصراف» و «تأیید» روشن؛ جلوگیری از بستن تصادفی وقتی داده‌ی واردشده از بین می‌رود |
| نوار کناری (Sidebar) | اپ‌های آیپد با بخش‌های متعدد | در آیفون معمولاً به نوار تب تبدیل می‌شود |
اشتباه رایج: منوی همبرگری در آیفون
بسیاری از اپ‌هایی که از روی نسخه‌ی وب یا اندروید قدیمی کپی شده‌اند، بخش‌های اصلی را پشت منوی همبرگری پنهان می‌کنند. در iOS این کار باعث می‌شود کاربر بخش‌ها را نبیند و کمتر سراغشان برود. اگر بیش از پنج بخش اصلی دارید، به‌جای منوی پنهان، بخش‌های کم‌کاربرد را زیر تب «بیشتر» یا «پروفایل» گروه‌بندی کنید.
ژست‌ها را جایگزین دکمه نکنید
کشیدن برای برگشت، کشیدن ردیف فهرست برای حذف یا آرشیو، کشیدن به پایین برای تازه‌سازی و نگه‌داشتن طولانی برای منوی زمینه، ژست‌های آشنای iOS هستند. اما ژست‌ها دیده نمی‌شوند؛ پس هر کار مهمی که با ژست انجام می‌شود باید راه قابل‌مشاهده‌ای هم داشته باشد. همچنین ژست‌های سفارشی نباید با ژست‌های سیستم، مثل کشیدن از لبه‌ی پایین برای رفتن به صفحه‌ی خانه، تداخل داشته باشند.
ناحیه‌ی امن، Dynamic Type و SF Symbols در طراحی اپلیکیشن iOS
سه مفهوم فنی هستند که تقریباً در هر صفحه‌ای از یک اپ آیفون اثر می‌گذارند و اگر طراح آن‌ها را نشناسد، طرح در اجرا به هم می‌ریزد.
ناحیه‌ی امن (Safe Area)
آیفون‌های جدید گوشه‌های گرد، جزیره‌ی پویا یا ناچ و نشانگر خانه در پایین دارند. ناحیه‌ی امن بخشی از صفحه است که محتوای تعاملی باید داخل آن بماند تا زیر این عناصر پنهان نشود. پس‌زمینه و تصاویر می‌توانند تا لبه‌ی صفحه ادامه پیدا کنند، اما دکمه‌ها، متن و فیلدهای فرم باید در محدوده‌ی امن باشند.
Dynamic Type و اندازه‌ی متن
کاربران iOS می‌توانند از تنظیمات سیستم اندازه‌ی متن را بزرگ یا کوچک کنند. Dynamic Type مجموعه‌ای از سبک‌های متنی معنادار مثل Large Title، Headline، Body و Caption است که با این تنظیم بزرگ و کوچک می‌شوند. اگر طرح با اندازه‌های ثابت پیکسلی ساخته شود، با بزرگ شدن متن، برچسب‌ها بریده می‌شوند و دکمه‌ها روی هم می‌افتند. ما در دییر صفحه‌های کلیدی را علاوه بر اندازه‌ی پیش‌فرض، در بزرگ‌ترین اندازه‌های دسترس‌پذیری هم طراحی و بررسی می‌کنیم؛ موضوعی که بخشی از طراحی دسترس‌پذیر است، نه یک امکان جانبی.
برای متن فارسی، فونت سیستمی iOS خط فارسی را پشتیبانی می‌کند، اما بسیاری از برندها فونت فارسی اختصاصی می‌خواهند. در این حالت باید فونت سفارشی به مقیاس Dynamic Type متصل شود و ارتفاع خط برای حروف فارسی کمی بیشتر در نظر گرفته شود تا نقطه‌ها و دندانه‌ها بریده نشوند.
SF Symbols
SF Symbols کتابخانه‌ی آیکون رسمی اپل است که هزاران آیکون هماهنگ با فونت سیستم دارد. مزیت اصلی آن این است که آیکون‌ها هم‌وزن با متن کنارشان رسم می‌شوند، با Dynamic Type بزرگ می‌شوند و نسخه‌های چندرنگ و متحرک دارند. برای اپ فارسی و راست‌چین دقت کنید آیکون‌های جهت‌دار مثل فلش برگشت یا «بعدی» باید در چیدمان راست‌به‌چپ قرینه شوند، اما آیکون‌هایی مثل ساعت یا علامت پخش نباید برعکس شوند. اگر آیکون اختصاصی برند لازم دارید، بهتر است آن را با همان قواعد وزن و ابعاد SF Symbols طراحی کنید تا در کنار آیکون‌های سیستمی ناهماهنگ نباشد.
مجوزهای دسترسی و حریم خصوصی را چطور طراحی کنیم؟
در iOS اپ برای دسترسی به دوربین، میکروفون، موقعیت مکانی، عکس‌ها، مخاطبین یا ارسال اعلان باید از کاربر اجازه بگیرد و این درخواست با پنجره‌ی سیستمی نمایش داده می‌شود. متن توضیح این پنجره را خود اپ تعیین می‌کند و اپل انتظار دارد دلیل واقعی و مشخص دسترسی را بگوید. اگر کاربر یک بار «اجازه نمی‌دهم» را بزند، اپ دیگر نمی‌تواند همان پنجره را دوباره نشان دهد و کاربر باید خودش به تنظیمات برود؛ پس زمان درخواست اهمیت زیادی دارد.
- درخواست در لحظه‌ی نیاز: اجازه‌ی دوربین را وقتی بخواهید که کاربر روی «اسکن» زده، نه در اولین باز شدن اپ.
- صفحه‌ی توضیح پیش از پنجره‌ی سیستم: یک صفحه‌ی کوتاه که بگوید چرا این دسترسی لازم است و کاربر چه چیزی به دست می‌آورد.
- مسیر جایگزین: اگر کاربر اجازه نداد، اپ نباید قفل شود؛ مثلاً به‌جای موقعیت خودکار، امکان انتخاب دستی شهر را بدهید.
- ردیابی شفاف: اگر اپ داده‌ی کاربر را برای ردیابی بین اپ‌ها و سایت‌های دیگر استفاده می‌کند، طبق چارچوب App Tracking Transparency باید جداگانه اجازه بگیرد.
- اعلان‌های سنجیده: اجازه‌ی ارسال اعلان را بعد از اینکه کاربر ارزش اپ را دید درخواست کنید.
در اپ آیفون، پنجره‌ی درخواست دسترسی فقط یک بار شانس دارد؛ اگر زمان و دلیلش را درست طراحی نکنید، عملاً آن قابلیت را از دست داده‌اید.
ساخت اپلیکیشن آیفون در ایران؛ واقعیت انتشار و توزیع
مهم‌ترین تفاوت ساخت اپلیکیشن آیفون برای بازار ایران، مسئله‌ی انتشار است. به دلیل تحریم‌ها، ثبت‌نام در برنامه‌ی توسعه‌دهندگان اپل و انتشار اپ در اپ‌استور برای افراد و شرکت‌های مستقر در ایران با محدودیت جدی روبه‌روست و سابقه‌ی حذف اپ‌های ایرانی از اپ‌استور هم وجود دارد. این شرایط ممکن است تغییر کند، پس هیچ مسیری را نمی‌توان «تضمینی» دانست و تصمیم‌گیری باید با در نظر گرفتن ریسک‌ها انجام شود.
در عمل، کسب‌وکارهای ایرانی معمولاً یکی یا ترکیبی از این مسیرها را بررسی می‌کنند:
- مارکت‌های ایرانی iOS: فروشگاه‌هایی مانند سیب‌اپ و اناردونی اپ‌های ایرانی را به کاربران آیفون می‌رسانند. نصب از این مسیرها معمولاً به روش‌های امضای غیرمستقیم وابسته است و ممکن است گاهی اپ‌ها از کار بیفتند و نیاز به نصب دوباره داشته باشند؛ شرایط و قوانین هر مارکت را باید به‌طور جداگانه و به‌روز بررسی کرد.
- وب‌اپ پیش‌رونده (PWA): نسخه‌ای تحت وب که کاربر از Safari به صفحه‌ی خانه اضافه می‌کند. نیازی به اپ‌استور ندارد و از نسخه‌های اخیر iOS اعلان وب را هم پشتیبانی می‌کند، اما به برخی امکانات بومی دسترسی کامل ندارد.
- اپ‌استور از طریق ساختار حقوقی خارج از ایران: برخی کسب‌وکارها با شرکت یا شریک خارجی اقدام می‌کنند که الزامات قانونی، مالی و ریسک‌های خودش را دارد و باید با مشاور حقوقی بررسی شود.
نکته‌ی طراحی اینجاست: مسیر توزیع روی تجربه‌ی کاربر اثر مستقیم دارد. اگر اپ از مارکت‌های ایرانی نصب می‌شود، بخشی از تجربه، یعنی راهنمای نصب، اعتماد به پروفایل و به‌روزرسانی، خارج از اپ اتفاق می‌افتد و باید برایش صفحه‌ی راهنما و پیام‌های روشن طراحی کرد. اگر PWA انتخاب شود، طراحی باید محدودیت‌های وب را بپذیرد و همان حس بومی iOS را تا حد ممکن بازسازی کند. همچنین درگاه‌های پرداخت ایرانی معمولاً با هدایت به صفحه‌ی وب کار می‌کنند و جریان بازگشت از درگاه به اپ باید با دقت طراحی و تست شود.
Swift یا فناوری چندسکویی؛ کدام برای ساخت اپلیکیشن iOS بهتر است؟
انتخاب فناوری فقط تصمیم برنامه‌نویسی نیست و روی طراحی، هزینه و نگه‌داری اپ اثر می‌گذارد. سه گزینه‌ی رایج عبارت‌اند از توسعه‌ی بومی با Swift و SwiftUI، و فریم‌ورک‌های چندسکویی مثل Flutter و React Native.
| معیار | بومی (Swift / SwiftUI) | چندسکویی (Flutter / React Native) |
|---|---|---|
| حس بومی iOS | کامل؛ کنترل‌ها و انیمیشن‌های سیستمی به‌طور پیش‌فرض | خوب، اما بعضی رفتارها باید جداگانه شبیه‌سازی یا تنظیم شوند |
| دسترسی به امکانات جدید iOS | بلافاصله پس از عرضه | معمولاً با تأخیر یا نیاز به کد بومی |
| یک کد برای iOS و اندروید | ندارد؛ اندروید تیم جدا می‌خواهد | دارد؛ بخش بزرگی از کد مشترک است |
| مناسب برای | اپ‌هایی که تجربه‌ی بومی و کارایی اولویت اصلی است | محصولاتی که هم‌زمان روی دو سکو و با بودجه‌ی محدودتر عرضه می‌شوند |
اگر بازار هدف شما در ایران است و بخش بزرگی از کاربرانتان اندرویدی هستند، فناوری چندسکویی اغلب انتخاب منطقی‌تری است؛ به شرط اینکه طراح حواسش باشد نسخه‌ی iOS صرفاً کپی نسخه‌ی اندروید نباشد. اگر محصول شما به امکانات خاص سخت‌افزار اپل، ویجت‌ها یا کارایی بالا وابسته است، Swift ارزش هزینه‌ی بیشترش را دارد. برای برآورد دقیق‌تر اثر این انتخاب روی بودجه، مقاله‌ی هزینه ساخت اپلیکیشن را ببینید.
یک دیزاین سیستم، دو رفتار بومی
رویکرد ما در دییر برای اپ‌های دوسکویی این است که هویت برند، رنگ‌ها، تایپوگرافی و اجزای محتوایی در یک دیزاین سیستم مشترک تعریف شوند، اما رفتارهای سیستمی مثل ناوبری، برگه‌ها، انتخابگرها و هشدارها در هر سکو بومی بمانند. توکن‌های طراحی این کار را ساده می‌کنند، چون یک مقدار پایه می‌تواند در هر سکو به شکل مناسب خودش ترجمه شود.
مراحل طراحی اپلیکیشن آیفون از ایده تا تحویل
فرایند طراحی یک اپ iOS در کلیات شبیه هر محصول دیجیتال دیگر است، اما در هر مرحله نکته‌ی مخصوص اپل وجود دارد:
- کشف و تحقیق: شناخت کاربران آیفون در بازار هدف، بررسی رقبا و تصمیم‌گیری درباره‌ی مسیر توزیع.
- معماری و جریان کاربر: تعیین بخش‌های نوار تب، عمق ناوبری و جاهایی که برگه یا مُدال لازم است.
- وایرفریم و پروتوتایپ: طراحی در قاب‌های واقعی آیفون با رعایت ناحیه‌ی امن و تست روی دستگاه واقعی.
- طراحی بصری: اعمال سبک‌های Dynamic Type، SF Symbols، حالت تاریک و حالت‌های مختلف هر صفحه.
- تست کاربردپذیری: آزمودن پروتوتایپ با کاربران واقعی آیفون؛ روش‌ها را در راهنمای تست کاربردپذیری توضیح داده‌ایم.
- تحویل به توسعه: مستندسازی اندازه‌ها بر حسب پوینت، رفتار در اندازه‌های بزرگ متن و قرینه‌سازی راست‌چین.
در پروژه‌هایی مثل کافه بازار دیده‌ایم که هماهنگی زودهنگام طراح و توسعه‌دهنده روی جزئیات سکو، بیشتر از هر ابزاری از دوباره‌کاری جلوگیری می‌کند. اگر به دنبال تیمی هستید که هر دو بخش را پوشش دهد، خدمات طراحی محصول و UI/UX و توسعه‌ی وبسایت و اپلیکیشن دییر را ببینید.
سؤالات متداول
آیا می‌توان در ایران اپلیکیشن آیفون منتشر کرد؟
بله، اما مسیر آن با کشورهای دیگر فرق دارد. انتشار مستقیم در اپ‌استور برای توسعه‌دهندگان مستقر در ایران محدود است و بیشتر کسب‌وکارها از مارکت‌های ایرانی iOS، وب‌اپ پیش‌رونده یا ترکیبی از این‌ها استفاده می‌کنند. هر مسیر ریسک و محدودیت خودش را دارد و باید پیش از شروع طراحی انتخاب شود.
حداقل اندازه‌ی دکمه در طراحی اپلیکیشن iOS چقدر است؟
راهنمای اپل حداقل ناحیه‌ی لمسی ۴۴ در ۴۴ پوینت را توصیه می‌کند. ظاهر دکمه می‌تواند کوچک‌تر باشد، اما ناحیه‌ی قابل لمس آن نباید از این اندازه کمتر شود.
آیا برای iOS و اندروید دو طراحی جداگانه لازم است؟
لزوماً نه. معمولاً یک دیزاین سیستم مشترک با هویت برند واحد ساخته می‌شود و فقط رفتارهای سیستمی مثل ناوبری، کنترل‌ها و برگه‌ها برای هر سکو بومی‌سازی می‌شوند.
PWA می‌تواند جایگزین اپ بومی آیفون شود؟
برای بسیاری از سرویس‌های محتوایی، فروشگاهی و رزرو، PWA گزینه‌ی قابل‌قبولی است و مشکل انتشار را حل می‌کند. اما اگر اپ به امکانات سخت‌افزاری، کار در پس‌زمینه یا تجربه‌ی کاملاً بومی وابسته باشد، محدودیت‌های وب در iOS محسوس خواهد بود.
طراحی اپلیکیشن آیفون با چه ابزاری انجام می‌شود؟
بیشتر تیم‌ها از ابزارهای طراحی رابط مثل Figma همراه با کیت رسمی رابط iOS که اپل منتشر می‌کند استفاده می‌کنند. برای پروتوتایپ‌های دقیق‌تر و بررسی رفتار واقعی، ساخت نمونه‌ی اولیه با SwiftUI و تست روی دستگاه هم رایج است.
اگر قصد طراحی یا بازطراحی اپلیکیشن iOS را دارید و می‌خواهید از همان ابتدا هم تجربه‌ی بومی آیفون و هم واقعیت انتشار در ایران دیده شود، تیم دییر آماده‌ی گفت‌وگو درباره‌ی محصول شماست. برای شروع، درخواست همکاری را ثبت کنید.
