Chapter 5 - Ethical and Social Impacts of Mobile Apps

5.1 The Digital Divide and Access to Technology

We often take technology for granted. If you’re reading this on a computer, using a school-issued device, or have access to Wi-Fi at home, you already have a huge advantage. But millions of people around the world—and even in your own community—don’t.

This gap in access is called the digital divide.

The digital divide is about more than just owning a smartphone. It includes:

Having reliable internet access
Using a modern, up-to-date device
Knowing how to navigate digital tools
Being able to afford data plans or app subscriptions
Accessing content in your preferred language or reading level

If developers and designers don’t consider these realities, they risk building apps that only serve a small group of people—usually people who already have power, access, and comfort with technology.

Who’s Affected by the Digital Divide?

The digital divide can affect:

Low-income families who can’t afford fast internet or modern devices
Rural communities with limited infrastructure
Elderly users who didn’t grow up with technology
People with disabilities who need accessible design
Non-native speakers who need content in other languages
Students who rely on shared devices or mobile data

Now think about this: if your app only works when connected to Wi-Fi, requires a brand-new phone, or assumes the user can read English perfectly—it’s not truly accessible.

How the Digital Divide Shows Up in App Design

Even simple design decisions can create barriers:

Large app size: If your app takes up 500MB, users with older phones may not have space to install it.
No offline mode: Users with limited data or no Wi-Fi might not be able to use the app at all.
High power usage: If your app drains the battery quickly, users might avoid using it to save energy.
Text-heavy design: If your app has dense reading material, users with limited reading skills or language proficiency may struggle.
One-language support: If your app is only in English, millions of people won’t be able to use it comfortably—even if the app is free and helpful.

These aren’t just small issues. They can make the difference between someone being included—or left behind.

Designing for Equity and Access

As a student developer, you have the power to close the gap—not widen it. Here are a few ways you can start designing more inclusive apps:

1. Make it Lightweight

Keep the app size small.
Limit the number of images and animations.
Compress content or provide basic versions of the app.

2. Support Offline Use

Cache (save) the most recent data so it works even without a signal.
Let users write or play offline and sync when they go online again.

3. Use Simple Language and Visuals

Avoid technical jargon.
Use icons and short sentences.
Offer alternate formats (voice, video, graphics).

4. Test on Older Devices

If possible, try your app on older phones or tablets.
See how it performs on slower connections.

5. Offer Language Options

Include multiple language choices in your UI.
Use icons to support understanding across cultures.

6. Include Accessibility Features

Add voice support or text-to-speech options.
Use readable font sizes and high-contrast colors.
Follow accessibility guidelines (like Android’s Material Design accessibility resources).

Real-World Examples

App Feature	Inclusive Design Choice
Educational app for remote areas	Includes offline lessons and syncs when online
Public health app for older users	Uses large buttons, clear text, and voice instructions
News app for international users	Offers translations and customizable reading levels
Job search app for rural workers	Works with 2G/3G networks and uses minimal graphics

Each of these examples shows how small design choices can lead to big increases in access.

Reflection: Who Are You Leaving Out?

As you build and test your own app, ask yourself:

Could someone in a rural or low-income area use this app?
What if the user has only 5% battery, no Wi-Fi, and an old phone?
Would someone with low literacy or a different native language understand this screen?
Am I assuming every user has unlimited data or tech skills?

By asking these questions early, you can avoid excluding people—without even realizing it.

Final Thoughts

The digital divide isn’t just a tech problem—it’s a social justice issue. And you, as a student developer, can help close it. You can build apps that include everyone, especially those who are usually left out.

Technology is powerful, but it’s only as good as the people it reaches.

As a developer, your job is not just to build something that works—it’s to build something that works for everyone.

5.2 Bias in Algorithms and UI Design

When you hear the word bias, you might think of unfair treatment, judgment, or stereotypes. In real life, bias can cause people to be excluded or misunderstood—and the same thing can happen inside of technology. Surprisingly, bias isn’t just a human problem—it can show up in the apps we build, even when we don’t mean for it to.

Bias in mobile apps can sneak into:

Algorithms that decide how your app works
User interfaces (UI) that affect who feels included—or left out
Data sets that shape how your app learns or responds

You don’t have to be trying to exclude anyone for bias to appear. That’s why it’s so important for developers to understand what bias looks like—and how to avoid it.

What Is Algorithmic Bias?

An algorithm is a step-by-step process your app follows to make decisions. For example:

A quiz app decides whether a user passed or failed.
A recommendation system shows new books based on past behavior.
A sorting tool ranks which items appear first on the screen.

But if the rules behind the algorithm are incomplete or based on limited assumptions, they might favor certain users over others. That’s called algorithmic bias.

Example 1: A Job Search App

If an app recommends jobs based only on past hires—and all the past hires were men—it may unintentionally stop showing listings to qualified women. That’s not fair, but it happens when the data and logic are biased.

Example 2: A Study Timer App

If an app gives extra points only to students who log in during school hours, it may unfairly punish users who work in the evenings or share devices with siblings.

Even small design decisions can have a big impact on user experiences.

What Causes Algorithmic Bias?

Bias can come from many places:

Training data that lacks diversity
Assumptions about who the user is
Testing done with only one group of people
Omissions in the logic or UI that make other options invisible

Most of the time, developers don’t mean to be unfair—but they may not realize who’s missing from their design or testing process.

Bias in UI Design

User interfaces can also introduce bias by excluding or misrepresenting users. For example:

A sign-up screen that only includes “Male” and “Female” options excludes nonbinary users.
A skin-tone emoji selector that defaults to light skin may feel less inclusive to some.
Color choices that make text hard to read can exclude users with vision differences.
Navigation menus that assume all users speak English fluently may frustrate non-native speakers.

Sometimes even the photos and illustrations in an app can send unspoken messages about who the app is for—and who it isn’t.

Spotting and Preventing Bias

As a developer or designer, your job is to create experiences that include everyone. To do that, you have to spot your assumptions before they turn into problems.

Ask yourself:

Who am I designing this app for?
Who might I be forgetting?
Have I tested this with people from different backgrounds?
What options are missing from my UI that users might expect?

Testing your app with a wide variety of people—including those with different genders, ethnicities, ages, and tech experience—can help you see blind spots early.

Best Practices for Fair and Inclusive Design

Area	Practice
Input Fields	Allow users to skip or customize identity questions
Language & Labels	Use simple, inclusive language and offer localization
Colors & Fonts	Use high contrast, readable fonts, and color-blind-friendly palettes
Content Choices	Avoid stereotypes in characters, examples, and images
Logic & Sorting	Make sure your app doesn’t favor one group unfairly
Accessibility	Design for different physical abilities, learning styles, and reading levels

Real-World Impact

When bias goes unchecked, it can do real harm:

Apps that fail to work for people with darker skin tones (like facial recognition)
Health apps that ignore women’s health data
Recommendation engines that reinforce stereotypes
Educational apps that assume every student has the same learning speed or resources

Even if your app is small or just for school, the way you design it sets the tone for how you’ll build in the future. Learning to recognize bias now helps you build better, more respectful technology later.

Final Thoughts

Bias in apps isn’t always easy to see—but it’s always important to look for. As a developer, you are shaping people’s experiences. You decide:

What choices they have
How they’re represented
Who gets to feel seen and supported

Inclusive design is not just about being politically correct. It’s about building apps that work better for everyone.

And the more people your app works for, the more valuable and powerful it becomes.

5.3 Safe Computing and Security Best Practices

When you build an app—especially one that collects or stores user information—you become responsible for something more than just making sure it works. You’re responsible for protecting the people who use it.

That means your app must be safe. It should protect the user’s privacy, prevent data leaks, and avoid being misused by hackers or bad actors. Even if your app isn’t handling bank information or social security numbers, it still might store things like:

Usernames
Passwords
Email addresses
Locations
Personal preferences
Photos or journal entries

If someone can misuse that data—or if your app accidentally leaks it—you could cause real harm. That’s why safe computing is not just an option—it’s a necessity.

Why Security Matters (Even for Students)

You might think, “I’m just building a project for class. Why does security matter?”

Because:

Every time you collect data, you have a responsibility to protect it.
If you build unsafe habits now, those will follow you into real-world development.
A vulnerable app—even a small one—can be a risk for users, schools, or businesses.

By learning security best practices early, you set yourself up to become a trusted, ethical developer.

Types of Risks in Mobile Apps

Risk	What Can Happen
Data Breach	Private user data is exposed or stolen
Insecure Password Storage	Hackers guess or steal weakly stored passwords
Unencrypted Communication	Hackers intercept what your app sends/receives over the Internet
Too Much Data Collection	Your app collects more than it needs, violating trust or laws
Improper Permissions	Your app asks for access to things (like camera or location) it doesn’t need
Code Vulnerabilities	Bugs or oversights let attackers exploit your app

Even beginner apps should take steps to minimize risk and respect privacy.

Basic Security Best Practices

Here are a few essential security habits that every app developer should follow—whether you’re just starting or preparing to publish on an app store:

1. Collect Only What You Need

The best way to protect user data is not to collect it in the first place.

Don’t ask for personal information unless your app truly needs it.
Avoid collecting location, photos, or contact lists unless it’s essential.
If users can remain anonymous, let them.

Rule of thumb: If you can’t explain why you’re asking for a piece of data, don’t ask for it.

2. Never Store Passwords as Plain Text

Storing a password like this is a big mistake:

val password = "secret123"

Even in a private app, storing raw passwords is dangerous.

Instead:

Use a secure hashing algorithm if you must store passwords.
Or better yet, use authentication APIs like Google Sign-In or Firebase Auth to handle login securely.

Letting trusted services handle login reduces your risk—and improves user trust.

3. Use HTTPS for All Communication

Whenever your app talks to a server, it must use HTTPS, not HTTP. The “S” stands for secure, and it means all data is encrypted.

Why it matters:

Without HTTPS, anyone on the same network (like a public Wi-Fi) could intercept your data.
That means passwords, messages, or user info could be exposed—even if you didn’t intend it.

Always double-check that every API you use supports HTTPS.

4. Ask for Permission the Right Way

Android apps often request access to:

Location
Camera
Microphone
Contacts
Files

You should only ask for permission if:

The feature can’t work without it
You clearly explain why you need it

Never surprise users with unexpected permissions. Always follow Android’s recommended permission request flow, and test what happens if the user says “no.”

5. Protect Data Locally

If you store anything on the user’s device, treat it like it could fall into the wrong hands.

Tips:

Use SharedPreferences for small pieces of data, but avoid storing sensitive information there.
For sensitive files or user entries, consider encrypting them.
Always give users a way to delete their data if they want to.

6. Plan for Mistakes

Even good developers make errors. So make sure your app can:

Handle failed network connections
Catch unexpected input or crashes
Recover gracefully (don’t expose stack traces or raw errors)

By building with security and resilience in mind, you create a better experience—and a more trustworthy product.

Respecting User Privacy

Security is about protecting users from harm, but privacy is about respecting their control and dignity.

Even if your app doesn’t get hacked, it can still violate someone’s trust if you:

Collect data without permission
Sell or share user data
Track people silently
Store personal information longer than necessary

Good developers respect privacy by design.

Let your users know:

What you’re collecting
Why you need it
How it will be used
Whether they can opt out

This is called transparency, and it builds long-term trust.

Final Thoughts

You don’t need to be a cybersecurity expert to write safe apps—but you do need to be careful, curious, and responsible.

As you continue building apps, always ask:

“Do I really need this data?”
“Am I storing or sharing anything sensitive?”
“What could go wrong—and how can I protect the user if it does?”

Being a developer isn’t just about solving problems—it’s also about protecting people.

5.4 Legal and Ethical Issues in App Development

As a developer, you’re not just writing code—you’re making choices that affect people’s lives. And once you release an app, those choices are no longer private. They’re public, real, and sometimes permanent.

That’s why app development doesn’t just involve technical skills. It also requires ethical thinking and an understanding of basic laws that protect users, developers, and businesses. Even if you’re not planning to publish your app yet, it’s important to learn these responsibilities early—because they only grow as your skills and projects expand.

In this section, you’ll explore the difference between what’s legal, what’s ethical, and why both matter when building apps.

What’s the Difference Between Legal and Ethical?

Legal means something is allowed (or required) by law.
Ethical means something is right, fair, and responsible—even if there’s no law about it.

Sometimes, something can be legal but still feel wrong. For example, it might be legal to collect certain user data—but unethical to do it without the user’s knowledge. As a developer, you want your work to meet both legal standards and ethical values.

Common Legal Considerations for App Developers

Here are some of the key legal topics that app developers (even students) should understand:

1. Data Privacy Laws

Many countries and U.S. states have privacy laws that say:

You must get permission before collecting certain data.
You must explain what you’re collecting and why.
You must protect user data and allow users to delete it.

Some of the most well-known privacy laws include:

GDPR (General Data Protection Regulation – used in the EU)
CCPA (California Consumer Privacy Act – used in California)
COPPA (Children’s Online Privacy Protection Act – applies to users under 13)

If you’re creating an app for students or young users, COPPA is especially important. It requires you to:

Get parental permission to collect data
Avoid unnecessary data collection
Clearly explain what information is stored

Even if your app is only for class, it’s smart to build privacy into your design now.

2. Copyright and Intellectual Property

Just because an image, song, or code is on the Internet doesn’t mean you can use it freely. Most media is protected by copyright.

That means:

You need permission to use photos, music, icons, or fonts that you didn’t create yourself.
You must credit the source or follow the license terms.
If you copy code from a website or open-source project, you must check the license to see if you’re allowed to reuse or modify it.

Using copyrighted materials without permission is not only unethical—it’s illegal. And it could get your app removed from stores or lead to legal trouble.

Instead, use:

Creative Commons media
Royalty-free music and images
Official APIs or SDKs with clear usage rights

3. Terms of Service and API Restrictions

When you use an API (like a weather service, translation tool, or social login), you are agreeing to the terms of service of the provider. These terms often include:

Rate limits (how many requests you can make per day)
Restrictions on how you can use or display the data
Rules about commercial use or reselling

Ignoring these rules can lead to your access being cut off—or worse.

Always:

Read the API’s documentation
Respect the rate limits
Avoid storing or sharing API data unless allowed

4. App Store Requirements

If you ever plan to publish your app on Google Play or the App Store, you’ll have to meet strict guidelines around:

Security
Privacy
Advertising
Age-appropriate content
Transparent data usage

Even classroom projects can benefit from following these standards—it builds professionalism and prepares you for real-world publishing.

Ethical Challenges in App Design

Legal rules are important, but ethics go even deeper. They ask:

“Is this the right thing to do—even if no one catches me?”

Some ethical dilemmas you might face include:

Should your app collect data about people without telling them?
Is it okay to design your app to keep users hooked (even if it’s distracting)?
Should you sell user data to advertisers if it helps keep your app free?
What should you do if someone uses your app to cause harm?

The answers aren’t always simple—but asking the questions makes you a better developer.

Best Practices for Legal and Ethical Development

Area	Responsible Practice
Data Collection	Ask for consent, explain why, and collect only what’s needed
Media Usage	Use your own work or properly licensed content
API Integration	Read the terms, respect limits, and use data as intended
User Privacy	Give users control over their data and offer clear privacy settings
Security	Encrypt sensitive data, use HTTPS, and never store passwords in plain text
Transparency	Be honest about what your app does, how it works, and who it serves

Final Thoughts

The best apps are not only well-designed and functional—they’re also built with integrity.

As you continue developing your skills, remember:

You are responsible for the tools you build.
You must protect users, respect their rights, and follow the rules.
And most importantly, you must think before you code.

Ask yourself:

“Would I be okay if an app did this to me?”
“Would I feel safe using this if I didn’t know how it worked?”
“Am I building something that helps people—or takes advantage of them?”

Legal knowledge protects you. Ethical thinking protects your users. Together, they make you a developer people can trust.

Discussion Prompt

“Imagine your app becomes wildly popular overnight. Millions of people use it every day—including people from different countries, age groups, income levels, and abilities. How would you feel knowing that a design choice you made could leave someone out, expose their personal data, or influence their behavior without them realizing it?”

Now discuss:

What responsibilities do you think developers have beyond writing code?
How can you design an app that respects privacy, includes everyone, and avoids bias?
What real-world examples have you seen where apps helped or harmed people?
What would you do differently in your app today if you knew it would impact people globally?

Extension (Optional):
As a group or class, create a “Developer’s Code of Ethics” with 3–5 principles that all ethical apps should follow.

Key Vocabulary

Term	Definition
Digital Divide	The gap between people who have easy access to technology and those who do not.
Accessibility	Designing apps so people of all abilities and backgrounds can use them easily and equally.
Bias	A preference or unfair influence in an app’s design or algorithm that may exclude some users.
Algorithmic Bias	When a set of rules in code makes unfair decisions based on flawed or limited data.
Inclusive Design	A design approach that makes sure apps work for users of all backgrounds, ages, and abilities.
User Privacy	The right of users to control their personal data and how it is collected and used.
Security	Protecting an app and its users from data leaks, hacks, or other risks.
Encryption	A way to hide information by turning it into a secret code that can only be read with a key.
Permission	Asking the user for access to data or features (like location or camera) before using them.
COPPA	A law that protects the online privacy of children under 13 in the U.S.
GDPR	A European law that gives people control over their personal data online.
Terms of Service	The rules and conditions users agree to when using an app or service.
Ethics	Principles about what is right and fair when making decisions, even if not required by law.
Copyright	A legal right that protects someone’s original work from being copied or used without permission.
Open Source	Software or content that anyone can use, change, or share, often with a license.