Remember that naive confidence from Part 1? Well, this is where it officially dies. Today we're diving into Apple's App Store Connect - a system that feels like it was designed by someone who really loves paperwork.

If you thought creating a simple product would be straightforward, prepare to discover that Apple has turned it into an art form involving endless forms, mysterious approval processes, and screenshots that nobody will actually look at.

⚡ Quick Setup Guide (Skip the Journey, Get It Done)

Need to set up IAP products fast? Here's the step-by-step without the commentary. For context and gotchas, read the detailed sections below.

Step-by-Step Apple IAP Setup

1. Navigate to IAP Section

• App Store Connect → My Apps → [Your App] → Montization → In-App Purchases → Click "+"

2. Choose Product Type ⚠️ Cannot be changed later

• Non-Consumable: Premium features, ad removal, permanent unlocks

• Consumable: Coins, lives, temporary items

• Subscriptions: Recurring access (complex setup)

3. Configure Basic Info

Product ID: com.yourapp.feature_v1 (permanent identifier)
Reference Name: "Premium Features" (internal only)
Price Tier: Pick from Apple's predetermined list

4. Localization ⚠️ Required for all supported countries

Display Name: "Premium Monthly"
Description: "Unlock advanced editing tools, exclusive templates, and priority support"

5. Screenshots (Subscriptions only)

• Show subscription benefits clearly

• Include text overlays explaining value

• Professional quality required

6. Submit for Review

• Status: "Waiting for Review"

• Timeline: 24 hours to 2 weeks

• Prepare for possible rejection and resubmission

7. Test in Sandbox

Create sandbox tester: App Store Connect → Users & Access → Sandbox Testers
Device: Sign out of App Store, don't sign back in until purchase prompt
Test: Look for [Environment: Sandbox] in purchase dialog

Common Mistakes to Avoid

• ❌ Generic product names ("Pro", "Premium")

• ❌ Missing localizations for supported countries

• ❌ Screenshots that don't match description

• ❌ Mixing sandbox and production Apple IDs

• ❌ Insufficient description detail

Quick Reference Links

• Detailed Apple Process: [See below sections]

• Product Type Selection: [Choosing Your Product Type section]

• Sandbox Testing: [Testing in the Sandbox section]

• Troubleshooting: [Common Issues section]

Need more context? Read on for the full journey, edge cases, and advanced scenarios.

🍎 Welcome to Apple's World of Forms

Apple's approach to IAP feels like they hired a bureaucrat from the DMV and said, "Make this more complex." Everything requires forms, approvals, and documentation that seems designed to test your commitment to mobile development.

Prerequisites (The Entry Fee)

Before you can even begin this journey, you'll need:

• Active Apple Developer Program membership ($99/year - your first IAP cost)

• App created in App Store Connect (even if it's not published yet)

• Valid iOS Distribution Certificate (because Apple loves certificates)

• Admin or App Manager role access (no peasants allowed)

Finding the IAP Section

Navigate to My Apps → Select Your App → Features → In-App Purchases. Click that innocent-looking "+" button and welcome to the maze where your optimism goes to die.

🎭 Choosing Your Product Type (Choose Wisely, Young Hobbit)

Here's where Apple shows its true nature - you get one shot at picking the right product type. No take-backs, no changes, no "oops I meant the other one." It's like choosing your house at Bag End - commit now, face consequences later.

Consumable Products

Perfect for things users buy repeatedly - coins, gems, lives, or your will to continue this project. These disappear after use like your sanity during this process.

Use cases:

• Virtual currency (coins, gems, credits)

• Temporary boosts or power-ups

• Extra lives or attempts

• Consumable items that get "used up"

The fine print: No restore functionality needed because they're meant to be consumed. Apple won't test restore for these.

Technical note: While Apple technically allows restore functionality for consumables (useful for refund scenarios), best practice is to not implement it since consumables should be "consumed" after use.

Non-Consumable Products

The "buy once, own forever" items - premium features, ad removal, or that sense of accomplishment when this finally works.

Use cases:

• Premium app features

• Ad removal

• Permanent character unlocks

• One-time feature purchases

⚠️ Critical requirement: These must have restore functionality because Apple will test it. Your app needs to remember these purchases across devices and reinstalls.

Auto-Renewable Subscriptions

The money printer - automatic billing and renewal with the most complex approval process known to mankind.

Use cases:

• Monthly/yearly premium memberships

• Content subscriptions

• Service access

• Feature subscriptions

The complexity warning: Requires additional setup including subscription groups, promotional offers, and enough documentation to fill a small library. We'll dive deep into this complexity below.

Non-Renewing Subscriptions

The manual labor version - fixed-term access that users must manually renew.

Use cases:

• Seasonal passes

• Course access

• Time-limited premium features

• Event-based subscriptions

Reality check: Most developers want auto-renewable subscriptions but end up here because the approval process is simpler.

⚠️ Critical Warning: Product type cannot be changed after creation. Choose carefully, or you'll be deleting products and starting over.

📱 Case Study: The Rejection Loop from Hell

Before we dive into configuration, let me share a real scenario that happened to a popular photo editing app (anonymized for obvious reasons).

The Setup: They launched with a simple "Premium Monthly" subscription offering advanced filters and cloud storage. Seemed straightforward enough.

The Reality:

• Attempt 1: Rejected for "insufficient description detail"

• Attempt 2: Rejected for "screenshot doesn't clearly show subscription benefits"

• Attempt 3: Rejected for "missing localization for French Canada" (they supported French, but not Canadian French specifically)

• Attempt 4: Rejected for "product name too generic"

• Attempt 5: Finally approved after 3 weeks

The Cost: 3 weeks of delays, missed marketing launch, frustrated team, and about 40 hours of developer time resubmitting the same product with minor tweaks.

The Lesson: Apple's review process for IAP products is just as unpredictable as app review, but with less clear feedback. Every detail matters, and "good enough" isn't good enough.

Now let's make sure you don't repeat their mistakes.

📝 The Product Configuration Gauntlet

Time for the real fun - filling out forms that feel designed to test your patience and attention to detail.

Product ID (Your Permanent Identity Crisis)

This is your unique identifier, and you're stuck with it forever. Apple prefers reverse domain notation, and they're very particular about format.

Apple's preferred format:

✅ Good: com.yourapp.premium
✅ Good: com.yourapp.coins_100
✅ Good: com.yourapp.monthly_subscription

❌ Bad: premium!
❌ Bad: my-product
❌ Bad: 123product
❌ Bad: Premium Features

The rules:

• Alphanumeric characters, dots, and underscores only

• Case-sensitive (they care about capitalization)

• Can start with letter or underscore

• Maximum 255 characters (generous compared to what's coming in Part 3)

Pro tip: Choose something descriptive but concise. You'll be typing this ID approximately 847 times during testing.

Reference Name (Your Internal Sanity Keeper)

This is what you'll see internally in App Store Connect. Make it descriptive because you'll be staring at it during 3 AM debugging sessions when nothing works and you're questioning your career choices.

Examples:

✅ Good: "Premium Monthly Subscription"
✅ Good: "100 Coins Pack"
✅ Good: "Remove Ads Forever"

❌ Bad: "Product 1"
❌ Bad: "Thing"
❌ Bad: "IAP"

Price Tiers (Apple's Price Prison)

Here's where Apple shows its control-freak nature. Want to charge $4.37? Too bad. You must pick from their predetermined price tiers.

Popular Price Tiers:

Pricing psychology tips:

• Tier 1 ($0.99) triggers impulse buying behavior

• Tier 3 ($2.99) is the most popular choice for small features

• Avoid "awkward" tiers like $7.99 - users prefer round numbers

• Higher tiers work for subscriptions but rarely for one-time purchases

💰 Complex Scenario: Multi-Region Pricing Strategy

Here's where Apple's price tiers become both a blessing and a curse. Let me walk you through a real-world pricing challenge.

The Challenge: You want to launch globally but need competitive pricing in different markets. A $9.99 subscription in the US might be too expensive in emerging markets but too cheap in premium markets like Switzerland.

Apple's Approach: You pick a tier, and Apple converts it globally using their predetermined rates:

The Problem: Apple's conversion doesn't consider:

• Local purchasing power

• Competitive landscape

• Cultural pricing preferences

• Economic conditions

Your Options:

Option 1: Accept Apple's Global Pricing

• Pros: Simple setup, consistent margins

• Cons: Uncompetitive in many markets, lost revenue

Option 2: Create Region-Specific Products

premium_monthly_us_v1    ($9.99 - Tier 10)
premium_monthly_eu_v1    (€7.99 - Tier 8) 
premium_monthly_in_v1    (₹449 - Tier 4)
premium_monthly_br_v1    (R$27.90 - Tier 6)

• Pros: Competitive pricing, better conversion

• Cons: Complex management, different feature parity

Option 3: Tiered Feature Model

basic_monthly_v1     ($2.99 global - Tier 3)
premium_monthly_v1   ($9.99 in rich markets - Tier 10)
premium_monthly_v1   ($4.99 in emerging markets - Tier 5)

• Pros: Market-appropriate pricing with feature differentiation

• Cons: Most complex to implement and maintain

Real-World Recommendation: Most successful apps start with Option 1 for simplicity, then gradually implement Option 2 for their top 5-10 revenue markets. The complexity isn't worth it until you have significant international revenue.

🌍 The Localization Nightmare

Here's where Apple's attention to detail becomes your personal nightmare. They want localized names and descriptions for every single country your app supports. Not just languages - countries.

The Scope of Madness

It starts innocently - "Display Name" and "Description" for English. Then you realize Apple wants separate entries for:

• English (United States)

• English (United Kingdom)

• English (Australia)

• English (Canada)

• English (India)

• ...and 40+ other English "variations"

Plus every other language your app supports.

What Apple Wants For Each Locale

Display Name: What users see in the purchase dialog

English (US): "Premium Monthly"
Spanish: "Premium Mensual"
French: "Premium Mensuel"
German: "Premium Monatlich"

Description: Detailed explanation of what they're buying

English (US): "Unlock all premium features including advanced editing tools, exclusive templates, and priority support."

Spanish: "Desbloquea todas las funciones premium incluyendo herramientas de edición avanzadas, plantillas exclusivas y soporte prioritario."

Translation Strategy (Don't Get Burned)

Option 1: Professional Translation

• Costs money but looks professional

• Culturally appropriate messaging

• Better conversion rates in international markets

Option 2: Google Translate

• Free but risky

• Can create embarrassing mistranslations

• "Premium Features" might become "High-Quality Characteristics"

Option 3: English Only

• Simple but limiting

• Reduced international appeal

• Apple may reject if your app supports multiple languages

⚠️ Rejection Warning: Missing localizations for countries your app supports = automatic rejection. Trust me on this one.

Smart Localization Tips

Start minimal: Only localize for countries that represent >5% of your user base Use consistent terminology: Keep product names similar across languages Cultural considerations: Some cultures prefer different value propositions Legal requirements: Some countries require specific subscription language

Reality check: Apple strongly recommends localization for all supported countries but won't automatically reject for missing translations if you provide comprehensive English (US) content. However, better localization = better user experience = higher conversion rates.

Advanced Localization Scenarios

The Family Sharing Complication: If your app supports family sharing, your product descriptions need to clearly explain what's shared vs. what's individual. Apple requires specific language:

✅ Good: "Premium subscription includes advanced features for the subscriber. Family members get basic access to shared templates."

❌ Bad: "Premium features for everyone in the family."

Subscription-Specific Requirements: Auto-renewable subscriptions need legal disclaimer text in many regions:

// Required for EU markets
"Subscription automatically renews unless auto-renew is turned off at least 24 hours before the end of the current period. Account will be charged for renewal within 24 hours prior to the end of the current period."

// Must be translated accurately - no Google Translate shortcuts

📸 The Screenshot Mystery (Subscriptions Only)

If you're dealing with subscriptions, Apple wants screenshots. Not of your app interface - screenshots that show what the subscription gives users. This is where things get weird.

What Apple Actually Wants

For subscription products:

• Screenshots showing subscription benefits

• Text overlays explaining the value proposition

• Professional-looking marketing materials

• Clear before/after comparisons

The reality gap:

• What you have: A half-finished app and growing existential dread

• What Apple wants: Professional marketing screenshots with perfect UI and compelling copy

Screenshot Requirements

Technical specs:

• JPG or PNG format

• Maximum 8MB file size

• High resolution (recommended: iPhone Pro Max dimensions)

• Clear, professional appearance

Content requirements:

• Show actual app features (not generic stock photos)

• Include text explaining subscription benefits

• Demonstrate clear value proposition

• Professional design quality

Examples of good screenshot content:

✅ Before/after showing premium features unlocked
✅ Feature comparison charts
✅ Screenshots with benefit callouts
✅ Value proposition overlays

❌ Generic app store screenshots
❌ Unrelated stock photos
❌ Poor quality or blurry images
❌ Screenshots that don't match the description

🧪 Testing in the Sandbox (Where Hope Goes to Die)

Apple's sandbox environment is where you'll test purchases without spending real money. In theory, it's simple. In practice, it's a special kind of purgatory designed to test your debugging skills and patience.

Creating Sandbox Testers (Your Fake Friends)

Step 1: Navigate to Users and Access → Sandbox Testers Step 2: Click the "+" button to add a new tester Step 3: Fill out the form with fake but realistic information

Required information:

Email: test1@yourdomain.com (must be unique, never used for real Apple ID)
Password: TestPassword123! (meet Apple's complexity requirements)
First Name: Test
Last Name: User
Date of Birth: Valid date (affects content ratings)
App Store Territory: Your primary market (US, UK, etc.)

⚠️ The Golden Rule: Never, ever use a sandbox Apple ID for real App Store purchases. Write this on a sticky note and put it somewhere visible. Mixing sandbox and production accounts creates permanent, unfixable problems.

The Sandbox Testing Process

Device preparation:

1. Go to Settings → App Store

2. Sign out of any existing Apple ID

3. DO NOT sign back in until your app prompts for purchase

Testing flow:

1. Launch your app

2. Trigger a purchase

3. iOS shows purchase dialog with [Environment: Sandbox] label

4. Sign in with sandbox Apple ID when prompted

5. Complete purchase (no real money charged)

6. Verify purchase processing in your app

Common Sandbox Issues That Will Ruin Your Day

"Cannot Connect to iTunes Store"

Possible causes:

• Mixed sandbox and production Apple IDs on the device

• Network connectivity issues

• Apple's sandbox servers having "a moment"

• Device region doesn't match sandbox account region

Solutions:

• Sign out of ALL Apple IDs, restart device, try again

• Use a different sandbox account

• Check Apple's system status page

• Wait (sometimes it's literally just Apple having server issues)

"Invalid Product Identifier"

Possible causes:

• Product not approved/released yet

• Typo in product ID in your app code

• App not using correct provisioning profile

• Product not available in sandbox account's region

Solutions:

• Verify product status in App Store Connect

• Double-check product IDs match exactly (case-sensitive!)

• Ensure app uses development or distribution provisioning profile

• Check product availability in tester's region

Purchase Dialog Shows Wrong Information

Possible causes:

• Cached product information

• Product information updated but not propagated

• Localization issues

Solutions:

• Delete and reinstall app

• Wait for Apple's cache to refresh (up to 24 hours)

• Test with different sandbox account

Purchases Succeed But Don't Register in App

Possible causes:

• Not properly listening for purchase updates

• Receipt validation logic errors

• Transaction finishing prematurely

Solutions:

• Check purchase observer implementation

• Verify receipt validation code

• Add extensive logging to debug transaction flow

🔄 Sandbox Testing: Advanced Scenarios

Beyond basic purchase testing, here are complex scenarios you need to verify in sandbox:

Testing Subscription Renewals

The Challenge: How do you test monthly/yearly renewals without waiting months?

Apple's Solution: Accelerated renewal rates in sandbox:

• 1 week subscription renews every 3 minutes

• 1 month subscription renews every 5 minutes

• 2 months subscription renews every 10 minutes

• 3 months subscription renews every 15 minutes

• 6 months subscription renews every 30 minutes

• 1 year subscription renews every hour

What to Test:

// Your app should handle:
1. Successful renewals (subscription continues)
2. Failed renewals (payment method expired) 
3. Canceled renewals (user turned off auto-renew)
4. Billing retry periods (Apple tries failed payments for 60 days)
5. Billing grace periods (temporary access during payment issues)

Testing Family Sharing

Setup Requirements:

• Multiple sandbox Apple IDs in same family

• Different devices or simulator instances

• Family organizer with valid payment method

Scenarios to Test:

• Purchase on organizer account, verify access on family member device

• Family member leaves family, verify access revocation

• Multiple family members try to access same shared purchase

Testing Promotional Offers

Prerequisites:

• Server-side signature generation setup

• Promotional offer configured in App Store Connect

• User eligible for promotional offer

Complex Flow:

// 1. Check user eligibility server-side
// 2. Generate promotional offer signature
// 3. Present offer in app
// 4. User accepts promotional pricing
// 5. Verify promotional receipt
// 6. Track promotional usage for business analytics

⏰ The Review Process (AKA "Pending Purgatory")

Apple's documentation cheerfully states that products are "usually reviewed within 24-48 hours." This is technically true in the same way that saying "it usually doesn't rain" is true - sometimes accurate, often wildly optimistic.

The Reality Timeline

Apple says: 24-48 hours Reality: Anywhere from 6 hours to 2 weeks, depending on:

• Phase of the moon

• Apple reviewer workload

• Cosmic alignment

• Whether Mercury is in retrograde

• Your karma from previous app submissions

Common Rejection Reasons (And How to Fix Them)

"Description doesn't clearly explain the product"

What Apple sees: Generic or vague description What you probably wrote: "Premium features" What Apple wants: "Unlock advanced photo editing tools, 50+ exclusive filters, and cloud storage for unlimited photos"

"Screenshot doesn't show the feature"

What Apple sees: Screenshot that doesn't match description What you probably did: Used generic app screenshots What Apple wants: Screenshots specifically showing subscription benefits with clear callouts

"Product name is confusing"

What Apple sees: Unclear or misleading product name What you probably wrote: "Pro" What Apple wants: "Pro Monthly Subscription" or "Premium Photo Editor"

"Insufficient localization"

What Apple sees: Missing translations for supported countries What you probably did: Only provided English text What Apple wants: Proper localization for every country your app supports

Appealing Rejections

If your product gets rejected:

1. Don't panic - it happens to everyone

2. Read the rejection reason carefully - Apple usually tells you exactly what's wrong

3. Fix the specific issues mentioned - don't change unrelated things

4. Resubmit promptly - delays don't help your review time

🎯 Apple Setup Survival Tips

Before You Start

• Plan your product hierarchy and naming scheme

• Prepare localized content for all target markets

• Create professional screenshots if doing subscriptions

• Set up sandbox testers before you need them

During Setup

• Double-check product IDs before submitting (you can't change them)

• Be specific and detailed in descriptions

• Include clear value propositions in product names

• Test everything in sandbox before submitting for review

After Approval

• Don't celebrate yet - implementation is where the real pain begins

• Keep sandbox accounts organized and documented

• Monitor for any status changes in App Store Connect

• Prepare for Part 3: Google's completely different approach

🚧 Coming Next

Congratulations! You've survived Apple's bureaucratic maze and successfully configured your first IAP products. Your products are now sitting in "Ready to Submit" or "Waiting for Review" status, and you're probably questioning why you didn't just become an accountant.

But don't rest yet - in Part 3: Google Play Setup, we'll discover that Google took a completely different approach to the same problems. Where Apple loves forms, Google loves flexibility. Where Apple has rigid rules, Google has mysterious algorithms.

It's like learning a second language where nothing translates directly from the first.

📋 TL;DR - Apple Setup Quick Reference

Bottom Line: Apple's IAP setup is bureaucratic but predictable. Follow their rules exactly, prepare for rejection cycles, and plan for complexity from day one.

Series Focus: While this guide covers all product types, we'll primarily focus on non-consumable products (premium features, ad removal, permanent unlocks) throughout the series. They represent the most common use case and have the most complex backend implementation challenges. Consumables and subscriptions follow similar setup patterns with variations we'll note where relevant.

Essential Steps Checklist

□ Choose product type carefully (can't change later)
□ Use reverse domain notation for Product IDs
□ Write detailed, benefit-focused descriptions
□ Localize for ALL supported countries
□ Create professional screenshots (subscriptions only)
□ Set up sandbox testers with unique Apple IDs
□ Test everything in sandbox before submitting
□ Prepare for 24 hours to 2 weeks review time
□ Plan for rejection and resubmission cycles

Critical Success Factors

🎯 Product Configuration:

• Product ID: com.yourapp.feature_v1 format

• Reference Name: Descriptive for internal use

• Price: Choose popular tiers (1, 3, 5, 10, 20)

• Descriptions: Specific benefits, not generic features

🌍 Localization Strategy:

• Start with top 5 revenue markets only

• Use professional translation, not Google Translate

• Include required legal language for subscriptions

• Plan for region-specific compliance requirements

🧪 Testing Approach:

• Never mix sandbox and production Apple IDs

• Test all subscription states (renewal, failure, cancellation)

• Verify family sharing behavior if enabled

• Test promotional offers with signature generation

⚠️ Common Pitfalls to Avoid:

• Generic product names ("Premium", "Pro")

• Missing localizations for any supported country

• Screenshots that don't match subscription benefits

• Insufficient description detail

• Wrong product type selection

Key Takeaways

1. Apple favors detail over simplicity - More information is always better

2. Rejection is normal - Plan for multiple submission cycles

3. Subscriptions are complex - Intro offers, promotions, and family sharing add significant complexity

4. Global pricing is rigid - Accept Apple's tiers or create region-specific products

5. Testing is critical - Sandbox environment catches issues before production

When to Consider Advanced Features

• Introductory Offers: If acquisition cost is high and you need conversion boost

• Promotional Offers: If you have significant churn and want win-back campaigns

• Subscription Groups: If you plan multiple subscription tiers

• Family Sharing: If your app has family-oriented features

Red Flags That Indicate Problems

• Product stuck in "Waiting for Review" > 1 week

• Repeated rejections for same issue

• Sandbox purchases not working after product approval

• Missing product options in sandbox testing

• Family sharing not working as expected

Survived Apple's bureaucratic gauntlet? Share your rejection stories in the comments. We're building a support group, and Apple App Store Connect trauma is our specialty.

Next is Part 3 - Google Play Setup, where we'll learn that "more flexible" doesn't necessarily mean "easier."

Warning: Long read. May contain 7 Tyrion Lannister Pro Tips

Management—this boogeyman word every developer hates or avoids. But hey, it doesn't have to relate to executive management specifically, or to be confined to the bureaucracy of institutions and companies.

There are possibly countless types of management—not in the sense that they are endless, but rather in their categorization and contextualization. From where I stand, I can speak about a few types: Self-Management, Task Management, Task Execution Management, and People Management.

My concern is about Self-Management and Task Execution Management. They are the most crucial types for devs and non-managerial positions, because they directly impact your—as a developer—daily progress and achievement. While other management types are important, e.g Task Management, which might be familiar to many teams and widely adopted in different forms like Agile methodology, I'm passing on them due to their organizational focus - they're externally structured frameworks that teams adopt rather than personal skills you develop.

Self-Management

Throughout my journey, I've met people with different self-management styles and personalities. Such observations extend to non-work related self-pillars like emotions, thoughts, and behavior. There are people who look like machines in terms of being fully self-managed; they manage their time, tasks, execution, emotions, thoughts, and so on. On the other side, there are people who need others to fully manage them, and of course there is a very wide range in between.

I'm not saying one of those styles is better than the other. Just as each person has their own genes, they have a different personality and type of self-management. If you accept this reality, this is what you get! But the important thing here is for someone with a need for "nano-management" to be aware of that. Being ignorant of such characteristics will put them out of their circle of competence and lead to focusing on distracting matters that would prevent their progress and reduce their productivity.

I encountered two kinds of people who need nano-management, not micromanagement. Some succeeded in carrying their duties because they were aware of the idea "this is what I can do," while the other type was not conscious about this "circle of competence"—as a concept, of course—which led them to chaos: missing deadlines, digging in the wrong place even with guidance and coaching, because they were refusing to admit the reality.

This is applicable to other areas - emotions for instance, which are generic, not limited to the workspace, and can reveal much about someone. Have you ever gotten into the office and seen your colleague's face about to explode? I bet this colleague of yours always lets outside variables affect their work performance and would need another person, maybe another colleague, to talk with—not in the sense of regular human interaction and discussion flow, but as a need for emotional direction.

An Islamic wisdom says "إنّ السماح رباح" which translates to "Allowance/Permitting is profitable"; that means giving people space to operate according to their nature, and permitting flexibility rather than imposing rigid control. It's about the profit that comes from allowing rather than restricting. And starting from oneself; you should allow your very nature, free from community and modernity stress. I knew a designer who was doing very impressive work; he could capture an idea and transform it into living graphics and animation, but he stressed himself trying to become an "entrepreneur". The word "سماح" also translates to "Forgiveness", and you might explore its relation to our context.

Speaking of myself: I struggle with vocally expressing ideas, as well as learning things at a good speed. I've come to the conclusion that I'm a slow learner and writer. That is fine; I've allowed myself to slowly learn and write, which in turn gave me a way to explore and understand complex and interconnected ideas on paper as iterations, rather than expressing them in linear sequencing—which speaking requires. So I embraced the mentioned saying above, kind of late.

I've succeeded in creating two new routines in my life; one is body activation to find the buried wisdom in flesh and bone. I'm not consistent in this routine—I don't show up at the gym every day—but I manage to find alternatives. The routine isn't about consistency; it's about recognition. Recognizing when my body needs movement to unlock or lock my mind. Sometimes that's the gym, sometimes it's pacing while debugging, sometimes it's just getting up from the damn chair. The second one is the mighty Sun Rituals. No further questions!

Self-management is sometimes sold as if you need to treat yourself as a project or a well-defined algorithm. In contrast, we are complex entities.

Self-management books and LinkedIn carousels love to pretend you're a simple system that just needs the right inputs and processes. "Follow these 7 steps!" "Use this productivity framework!" "Optimize your morning routine!" As if humans were machines that respond predictably to the same commands every day.

But we're not algorithms. We have moods, energy cycles, creative blocks, emotional baggage from yesterday's failed deploy, or excitement about a new technology we want to try. Some days you're laser-focused, other days your brain feels like spaghetti code.

The productivity gurus want you to believe consistency is king—same routine, same methods, same outputs. But real self-management means working with your inconsistencies, not against them. It's more like debugging a complex system where the variables keep changing.

Maybe today you need nano-management (strict structure), tomorrow you need complete freedom to explore. Maybe this week you're energized by hard problems, next week you need easy wins to rebuild confidence. The complexity is the point. Managing a complex entity requires flexibility, not rigid frameworks.

Am I anti-consistency? I don't think so. I'm against how it has been framed to us.

The "Strongly Typed vs Loosely Typed" analogy

Speaking coding language: keep your bigger picture/goals/milestones strongly typed—so core principles stay consistent. But adapt to loosely typed implementation based on context. You aren't going to create chaos, but flexibility instead. You'll have patterns, but not necessarily repeat yourself every day. This liquid world, as Bauman has described, will require you to allow this liquidity to pass, but not be affected by it. In this liquid modernity combined with your sophisticated personal circumstances: allowance and flexibility are survival necessities.

Personal creative processes aren't meant to be "managed" in the sense of standardization, systemization, or formalization. Imagine someone telling Leonardo da Vinci: "Hey, follow this framework, and you'll produce the most famous drawing ever." The absurdity is obvious—creativity resists systematization. But they can and should be self-micro-managed. So, Task Execution Management is an informal, non-universal, unofficial type you could call Micro-Decision Management, Self-OS, or keep it under Self-Management. You don't need to label it in the first place.

Task Execution Management

Now to the Ghoul!

I love Agile and its easing process. Once the sprint has started and you pick your first ticket, all echoes from the past start hunting you!

It doesn't matter what your code-level seniority is; what matters is your ability to manage this every time and every day, because each task is unique however similar it is to other tasks you've done before. You might already be confident about what you are going to do, but I bet you cannot explain the "How" each time in the same steps. If you fail to admit this, you've created another issue for yourself. Also, I haven't worked in big corporations, so I'm not aware of their processes, knowledge bases, or orientation programs that might help with task execution—this is coming from smaller team/startup experience.

No fancy promises such as you'll find here a "7 Ways To Flourish While Executing Your Daily Tasks"—which could be one of the top sellers in the future—guide. This would be exploring and insights sharing—you might find it useful and you may not. Also, none of my claims come from profound research; they are all raw observations and notes.

Whatever you are up to, don't start coding immediately—just don't!

Philosophers taught us about important life questions, which also happen to exist in most learning paths: What? When? Where? Who? Why?

The good news: you don't have to answer the immediate "Why" like "why am I doing this task?" either from a business perspective or from your existential perspective. Also, you can safely eliminate the "Who" as no one else will do your job. I intentionally dropped the "How" as, if you remember, it is the main one you are trying to answer yourself silently.

"What"

Probably this is the easiest question, and most likely well defined in your board ticket, and you may even have a good picture of its implementation. Despite that, it is a tricky one, and highly interconnected with "When" and both need to be managed simultaneously.

"Where"

I take time to scan a project, even though I'm living with it every day and see those lines that blur my eyes more than my kids. I have to do this every time, regardless of whether I'm working solo or within a team. It's like a recap of what has been done; what to use; what to avoid duplicating; where the new service or new model shall live. It helps you strategically build the picture in your mind, and once it's there, you can blueprint on paper, draw a diagram, whatever suits you!

If I have to pick for you, I'd say start with 'Where' - it will be your friend. Unlike "What" which can spiral into endless requirements analysis, or “When” which opens the door to decision paralysis, "Where" grounds you in the actual codebase reality. It forces you to do that essential scanning ritual, rebuilding your mental map even when you think you know the code intimately. Starting with 'Where' prevents the common mistakes of duplicating functionality, breaking existing patterns, or creating isolated code islands, and it naturally connects to that "don't start coding immediately" wisdom - making you pause, think strategically, and build that blueprint in your mind before your fingers hit the keyboard.

Starting from the wrong place will create a time vortex like the ones Dr. Strange does, except you don't have the time stone or any Ancient One to guide you out. You need precision that will relieve you of the burden of answering other questions.

Starting from "Where" might slow you down - short-term - but definitely will keep you on track - long-term benefit for better decisions, fewer rewrites, and cleaner execution.

"When"

This is a branched question that might hit technical and non-technical territories. I've been asked these kinds of questions while giving a training session, and honestly I did not have a clear answer that a fresh graduate would be satisfied with.

Have you ever asked yourself:

• When to start with UI and when with the data layer?

• When to ask for help versus struggle alone?

• When to refactor versus when to just make it work?

• When to reset and when to proceed? (It is not obvious, by the way.)

• When to over-engineer or under-engineer?

• When to optimize for performance versus readability?

• When to write tests first versus after?

• When to tackle the hard part first versus start with easy wins?

• When to make judgment calls versus have strict definitions?

Pay attention during this stage of your execution, and if you followed the 'Where' advice, it might save you a lot of hassle. In this era, you're either under-productive or super productive; either way, pause. Such questions interfere with the organic "How", and if you want to be productive, never count lines. This is the big dilemma I'm wrestling with right now.

Sometimes you have to make judgement calls - stress on your instinct, conduct quick research, depend on your experience in similar cases, future proof thinking. But here's the thing: there's no universal formula for these decisions. What works in one context fails in another.

SE guidelines are great, when you are looking for "textbook answers", but they assume rational conditions, stable teams, and predictable environments. They don’t count your energy level, team dynamics, political pressure, real-word chaos, legacy codebase constraints, skill gaps, or business priorities.

For example, books say "Start with data layer" or "Start with UI" or "It depends", but rarely address what to do when you're solo switching contexts constantly, when business pressure forces a specific approach, when legacy constraints limit your choices, or when you're not sure what the final product should be.

The books assume you have time for proper analysis - they don't cover "I need to deliver something in 3 days and I'm not sure what the stakeholder actually wants."

Sometimes you'd start with UI to digest the complex requirements, other times you’d start with a simple function, more frequently you'll have to lay out the data foundation at the very beginning.

Your "when" instincts improve with experience, but they're always contextual. The same developer who knows exactly when to optimize for performance in a fintech app might be completely lost about when to write tests in a creative prototype.

The goal isn't perfect timing - it's conscious decision-making. Even when you get it "wrong," knowing why - tactical why - you made the choice helps you calibrate for next time. The developers who struggle most are the ones who make these decisions unconsciously, then wonder why their instincts never improve.

So yeah, even in ones and zeros world, developed instinct still valid.

"How"

As the above elaboration on questions may help you slightly in answering the main "How," keep in mind: the notes from the previous questions do not, in any way, mean to ignore guidelines. You still need to confirm the following practices while answering them: Clean Code, Best Practices, Authentic sources, team documentation and knowledge bases, SOLID and DRY, and all other hot stuff.

Our "How" isn't a tutorial; it's a survival kit that will activate as a primal instinct once you're trapped. To sum up, you'll keep bouncing between "What" and "Where" for a while until you have your mind-map fully developed, stepping into the next stage where all the magic happens. As simple as this, right?

The Existential Thread

On Context and Complexity: I'll just remind you that there are no constants—rather the ones you define in your code—in all of that. So yes, context matters. Starting from your workspace, your development environment, to the exact case and scenario you are dealing with at the moment.

While Software Engineering focuses on disciplining development practices and processes, I'm tackling the individual psychology and real-time decision-making that happens within those processes—exploring how management concepts can help navigate the messy human side of coding.

On the "Why" Trap: Starting with "Why" will lead you to an Existential Crisis; avoid it unless you are ready to fight these battles every day. You start with "when should I use this design pattern" and suddenly you're questioning the nature of universal truth, which is also typically not management's primary domain. But it also happens that practical whys (i.e., choosing one architectural pattern over another for maintainability over performance considerations) lead to the land of existential mines: Why this algorithm? For better performance. Why better performance? For user satisfaction. Why user satisfaction? For business success. Why business success? For... career advancement? Personal fulfillment? Societal contribution? Why do any of those matter? What's the point of any of this work? Why am I spending my finite existence writing code? If you happen to fall into this trap, run, lift weights, tire your body out. Nothing defeats the mind like exhausting the body.

On Effectiveness vs. Balance: I'm not a fan of "work-life balance"; I'm a fan of "being effective in what you are doing," which might require you to balance things. This means developing mental structures, coping mechanisms, and agility and flexibility to get things done.

On Perspective and Reality: Absolutely, my notes are irrelevant to other contexts, especially stable and systematic environments. But from where I'm talking, managing any task, let alone completing it, in Palestine is a victory over reality (Militarized, Brutal, yet Liquid Modernity), not just an achievement.

On Dramatic Transformation: Embrace the concept "The deceived is the one whose days are equal" to ensure forward movement without falling into the "why" trap. Switching between implementations while maintaining core principles will definitely add to your day.

On Unconscious Competence: The best self-management often happens when you're not consciously managing - just following your natural rhythms and instincts.

Tyrion Lannister Pro Tips

I'm not trying to sell my word as other men's wisdom :) but you could use of them:

• Stick to your circle of competence, even if only momentarily.

• Allowance is profitable, restricting is costly.

• Answer the questions, even implicitly.

• Start with "Where" not with coding, or "Why".

• "Why" is a divisive question. Important in some contexts.

• When you are under-productive, stop.

• When you are super-productive, also stop.

Yes, I accidentally created two sets of 7 points while making fun of '7 Ways' frameworks. The irony is not lost on me. 😄

Once upon a time, we had a beautiful, well-designed, clearly documented mobile app. Everything was in harmony — code, design, logic — a dev’s little utopia.

Then came the twist:

“Users should be able to buy items.”

Fair enough. I’ve built dozens of apps with third-party payment gateways — Stripe, PayPal, you name it. We scoped the vision, locked the timeline, and moved forward confidently.

But then the client dropped the bomb:

They had to use the official App Store / Play Store IAP system.

I paused, blinked, and thought,
“No big deal. How bad could it be? It’s just another payment gateway… right?”

— Naive me, 72 hours before descending into IAP hell.

💭 What I Thought vs. What Actually Happened

What I expected:
A weekend project with clean documentation and straightforward integration.

What I got:
A month-long odyssey through bureaucratic nightmares, cryptic error messages, and the kind of debugging sessions that make you reconsider your career — and sanity.

🚀 The Journey Ahead

This series will walk you through the complete IAP implementation — the good, the bad, and the “why-is-this-even-a-thing” ugly. This series covers the complete IAP gauntlet:

Part 2: Store Setup – The Bureaucratic Maze

Setting up products in both App Store Connect and Google Play Console sounds simple — until you realize each platform speaks a different language.
We’ll dive into the endless forms, approval purgatory, and the mysterious art of getting test products to actually show up in sandbox mode.
Spoiler alert: “Pending review” will become your least favorite phrase.

Part 3: Ionic Capacitor Implementation – When Plugins Attack

Integrating IAP into Ionic + Capacitor should be plug-and-play, right? Wrong.
We’ll explore the fragmented plugin ecosystem, outdated docs, and the joy of discovering that what works on iOS breaks Android — and vice versa.
Plus: the not-so-universal "purchase flow."

Part 4: The Sync Nightmare – When Reality Hits

Here’s where things get spicy.
Users buy products, but your backend doesn’t know.
Receipts validate but aren’t delivered.
Network failures create zombie transactions.
We’ll tackle:

• Receipt validation

• Webhook reliability

• The dark art of syncing chaotic platforms

Part 5: Admin Features – The Control Room

Nothing says “pro” like giving your client full control without touching App Store dashboards.
We’ll build an admin interface to:

• Track purchases

• Handle refunds

• Manage IAP products

A lifesaver for you, and your client’s support team.

🧯 The Reality Check

If you're about to embark on your own IAP journey, buckle up.
This isn't your average API integration. It’s a multi-platform, multi-store, multi-headache saga that will test your patience, your debugging skills, and possibly your relationship with mobile development.

But once you survive it — and you will — you’ll have conquered one of mobile’s most notorious dragons.

And hey, you’ll have some killer war stories for your next dev meetup.

Coming Soon

🚧 Part 2: Store Setup – The Bureaucratic Maze

💡 As time allows:
I’m building MikaIAP — a full open-source In-App Purchase system using Ionic, NestJS, and MikaForm. Stay tuned for the GitHub release when it’s ready,